Re: Out-of-tree modules [was: Linux Security *Module* Framework]
On Oct 29 2007 20:46, Lee Revell wrote: >On 10/29/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote: >> quad_dsp - http://jengelh.hopto.org/p/quad_dsp/ >> >> Provides a /dev/dsp style node for legacy applications that support >> neither ALSA nor the AOSS wrapper nor more-than-2-channel sound. >> > >(I think that should read "AND more than 2 channel sound") It is for programs that only give out 2 channels of audio data. Qdsp_dpl2 is a node that applies the DPL2 matrix on these two channels, yielding the rear 2 channels, giving some sort of surround effect. >Couldn't ALSA's OSS emulation be extended to support more than 2 >channels per device node? I figured that exceeded my skills at that time. >> thkd - >> ftp://ftp5.gwdg.de/pub/linux/misc/suser-jengelh/kernel/linux-2.6.23.1-ccj58/thkd.diff >> >> Workaround for Toshiba MK2003GAH hard-drive head auto-unloading after >> 5-15 seconds. (Ref: http://lkml.org/lkml/2006/11/15/100 ) > >It looks like this could be trivially fixed in a mergeable way. That >LKML thread petered out before the problem was seriously analyzed. > >Did you try the -Z flag of hdparm? IIRC, yes, been through all sorts of hdparm options. -Z did not help at all, and -B only prolonged the delay from 5 to around 15 seconds. I contacted Tosh Corp (before posting on lkml) and while they know of the 'issue', I did not get a satisfactory answer (namely how to FIX it), so I thought why spend time slapping if there's a workaround... Causing a minimal head seek every now and then (4096 bytes per 3 seconds is a somewhat small block size with a not-too-low interval) is a working workaround for now. The module code is not top notch, but I doubt I'll ever have more than one 1.8" MK2003GAH disk in the same laptop. - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Out-of-tree modules [was: Linux Security *Module* Framework]
On 10/29/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote: > quad_dsp - http://jengelh.hopto.org/p/quad_dsp/ > > Provides a /dev/dsp style node for legacy applications that support > neither ALSA nor the AOSS wrapper nor more-than-2-channel sound. > (I think that should read "AND more than 2 channel sound") Couldn't ALSA's OSS emulation be extended to support more than 2 channels per device node? > > thkd - > ftp://ftp5.gwdg.de/pub/linux/misc/suser-jengelh/kernel/linux-2.6.23.1-ccj58/thkd.diff > > Workaround for Toshiba MK2003GAH hard-drive head auto-unloading after > 5-15 seconds. (Ref: http://lkml.org/lkml/2006/11/15/100 ) It looks like this could be trivially fixed in a mergeable way. That LKML thread petered out before the problem was seriously analyzed. Did you try the -Z flag of hdparm? Lee - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Out-of-tree modules [was: Linux Security *Module* Framework]
On Oct 25 2007 19:56, Greg KH wrote: >What kind of code is not accepted into the mainline kernel tree for good >reasons? What are these reasons? What specific code are you talking >about? > >I'm trying to compile a list of all known external modules and drivers >and work to get them included in the main kernel tree to help prevent >these kinds of things. If you know of any that are not on the list at: > http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers >please feel free to add them, or email me with the needed information >and I will add them to the list. quad_dsp - http://jengelh.hopto.org/p/quad_dsp/ Provides a /dev/dsp style node for legacy applications that support neither ALSA nor the AOSS wrapper nor more-than-2-channel sound. thkd - ftp://ftp5.gwdg.de/pub/linux/misc/suser-jengelh/kernel/linux-2.6.23.1-ccj58/thkd.diff Workaround for Toshiba MK2003GAH hard-drive head auto-unloading after 5-15 seconds. (Ref: http://lkml.org/lkml/2006/11/15/100 ) - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: eradicating out of tree modules (was: Linux Security *Module* Framework)
On Sat, Oct 27, 2007 at 04:07:41PM +0200, Tilman Schmidt wrote: > Greg KH schrieb: > > On Fri, Oct 26, 2007 at 11:46:39AM +0200, Tilman Schmidt wrote: > >> [...] I still think there will always be > >> a number of external modules that cannot be merged right now or at > >> all, and deliberately making life difficult for out-of-tree code > >> maintainers in order to coerce them into submitting their code for > >> inclusion in the kernel will not work, it'll only create bad > >> feelings. > > > > Do you have examples of proof of this? > > No proof in the legal, mathematical or scientific sense of the > term, but examples: > > - at least one talented kernel developer giving up his work, > until then maintained out of tree, after submitting it for > inclusion in the kernel and taking the ensuing fla^Wdiscussion > on LKML (nothing extraordinary, just the usual lack of > courtesy and respect) too much to heart >... There's one important point to note: In a project of the size of the Linux kernel (at about 2000 distinct people contributing code within one year) you will always lose developers: If you require too much from code for getting it included you lose some of the people who develop code. If you accept code of dubious quality you lose some of the people who care about the quality of the kernel. And if you add a stable API for modules with not GPL compatible licences at least one untalented kernel developer (me) might give up his work. If your goal is to please all developers you have a goal you can't achieve. The only reasonable way is to accept that whatever you do you'll lose some people and go in the direction you consider the right one. And the power of open source is that when an open source project gets into a direction many people dislike they can simply fork it. Consider e.g. XFree86->X.Org or NetBSD->OpenBSD. And that's nothing bad - either the forks develop in different directions creating different useful software or there's an evolutionary contest for the best software. > T. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: eradicating out of tree modules (was: : Linux Security *Module* Framework)
On Sat, Oct 27, 2007 at 04:47:15PM +0200, Tilman Schmidt wrote: > Adrian Bunk schrieb: > > On Fri, Oct 26, 2007 at 11:46:39AM +0200, Tilman Schmidt wrote: > >> On Thu, 25 Oct 2007 19:56:47 -0700, Greg KH wrote: > >>> On Fri, Oct 26, 2007 at 01:09:14AM +0200, Tilman Schmidt wrote: > [...] Once you admit that there is code which, for very good > reasons, won't ever be accepted into the mainline kernel tree, what you > are saying amounts to: "Code that isn't fit to be included in the > mainline kernel isn't fit to exist at all." > >>> What kind of code is not accepted into the mainline kernel tree for good > >>> reasons? > >> - proprietary code > > > > It's unclear whether distributing not GPL compatible modules is legal > > at all. > > We're neither talking about distribution nor legal aspects, but > about existence. But anyway, you seem to agree with me that there > are very good reasons for not including these in the kernel. > > > And they are definitely not "very good reasons" for doing anything in > > the kernel. > > There is a big difference between "not doing anything to help" > and "actively doing something to make life difficult for". The > former is undoubtedly legitimate. It's the latter we're > discussing here. Justifying anything with code with not GPL compatible licences has zero relevance here. And there's value in making life harder for such modules with questionable legality. As an example, consider people who experienced crashes of "the Linux kernel" caused by some binary-only driver. Not that uncommon e.g. with some graphics drivers. This harms the reputation of Linux as being stable. The solution is not to support proprietary drivers, the solution is to get open source replacements. >... > >> - code conflicting with existing kernel structure or policy > >> - code in which the concerned subsystem maintainers see no benefit > > > > Let's fix the problems, not work around them. > > That's certainly better, but not always possible. Do you > agree with me that if it isn't, then that's a very good > reason for not including that code in the kernel? No, it's still a reason for fixing the real problem. > > There is a conflict between getting code included and ensuring some > > minimum quality of the kernel, but in many cases we could try better. > > Correct. Again, you appear to agree with my statement that > for some code there are very good reasons not to include it > in the kernel. But this does not result in any obligation of supporting low quality external code that destabilizes the kernel of people using it. If it's low quality code doing something useful - well, how many hundred people are on Greg's list only waiting for some driver they could write? > > And when there's a good reason for a kernel policy, then code that > > violates this policy is not a "very good reason" for anything. > > >> - code which its author is unable and/or unwilling to convert to > >> kernel coding standards > >> - code whose author is unable and/or unwilling to defend it on LKML > >> ... > > > > That's their fault, and definitely not a "very good reason" for making > > life easier for them. > > Putting aside the fruitless question of whose fault it is, > is it a "very good reason" for actively making life more > difficult for them than it is already, eg. by gratuitiously > breaking interfaces they rely on for no other "very good > reason" than to discourage out-of-tree development? In other > words, do you think it benefits the Linux community if you > discourage those programmers you've already scared away from > submitting their code to the kernel from continuing their > work off-tree, too? In summary, do you think the world would > be a better place if all the existing out-of-tree modules > just ceased to exist, without any replacement? With your "without any replacement" you needlessly excluded the reasonable solution: The solution is that someone other than the author either takes the existing external code or rewrites it from scratch, submits it for inclusion into the kernel, and maintains it there. Let me repeat that Greg has said he has hundreds of volunteers for such tasks. > T. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
eradicating out of tree modules (was: : Linux Security *Module* Framework)
Adrian Bunk schrieb: > On Fri, Oct 26, 2007 at 11:46:39AM +0200, Tilman Schmidt wrote: >> On Thu, 25 Oct 2007 19:56:47 -0700, Greg KH wrote: >>> On Fri, Oct 26, 2007 at 01:09:14AM +0200, Tilman Schmidt wrote: [...] Once you admit that there is code which, for very good reasons, won't ever be accepted into the mainline kernel tree, what you are saying amounts to: "Code that isn't fit to be included in the mainline kernel isn't fit to exist at all." >>> What kind of code is not accepted into the mainline kernel tree for good >>> reasons? >> - proprietary code > > It's unclear whether distributing not GPL compatible modules is legal > at all. We're neither talking about distribution nor legal aspects, but about existence. But anyway, you seem to agree with me that there are very good reasons for not including these in the kernel. > And they are definitely not "very good reasons" for doing anything in > the kernel. There is a big difference between "not doing anything to help" and "actively doing something to make life difficult for". The former is undoubtedly legitimate. It's the latter we're discussing here. >> - unmaintained code > > Unmaintained code in the kernel has a realistic chance of being usable > for 5 years. > > Unmaintained external code is quite likely to be unusable after > at most one year. Then why is "being unmaintained" being toted as an argument *against* inclusion in the kernel? >> - code conflicting with existing kernel structure or policy >> - code in which the concerned subsystem maintainers see no benefit > > Let's fix the problems, not work around them. That's certainly better, but not always possible. Do you agree with me that if it isn't, then that's a very good reason for not including that code in the kernel? > There is a conflict between getting code included and ensuring some > minimum quality of the kernel, but in many cases we could try better. Correct. Again, you appear to agree with my statement that for some code there are very good reasons not to include it in the kernel. > And when there's a good reason for a kernel policy, then code that > violates this policy is not a "very good reason" for anything. >> - code which its author is unable and/or unwilling to convert to >> kernel coding standards >> - code whose author is unable and/or unwilling to defend it on LKML >> ... > > That's their fault, and definitely not a "very good reason" for making > life easier for them. Putting aside the fruitless question of whose fault it is, is it a "very good reason" for actively making life more difficult for them than it is already, eg. by gratuitiously breaking interfaces they rely on for no other "very good reason" than to discourage out-of-tree development? In other words, do you think it benefits the Linux community if you discourage those programmers you've already scared away from submitting their code to the kernel from continuing their work off-tree, too? In summary, do you think the world would be a better place if all the existing out-of-tree modules just ceased to exist, without any replacement? T. - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
eradicating out of tree modules (was: Linux Security *Module* Framework)
Greg KH schrieb: > On Fri, Oct 26, 2007 at 11:46:39AM +0200, Tilman Schmidt wrote: >> [...] I still think there will always be >> a number of external modules that cannot be merged right now or at >> all, and deliberately making life difficult for out-of-tree code >> maintainers in order to coerce them into submitting their code for >> inclusion in the kernel will not work, it'll only create bad >> feelings. > > Do you have examples of proof of this? No proof in the legal, mathematical or scientific sense of the term, but examples: - at least one talented kernel developer giving up his work, until then maintained out of tree, after submitting it for inclusion in the kernel and taking the ensuing fla^Wdiscussion on LKML (nothing extraordinary, just the usual lack of courtesy and respect) too much to heart - the furious flames on LKML each time someone dares posting helpful information about getting non-GPL software working again with the newest kernel version, which will certainly never achieve inclusion of that software in the kernel but definitely create bad feelings on both sides (righteous indignation *is* a bad feeling in my book) > Read Documentation/stable_api_nonsense.txt for how we already make > out-of-tree code developer's lives hell :) Oh yes, that one. A key piece of evidence. Yes, I've read it, though I sometimes wish I hadn't. Its very title supports my observation on the creation of bad feelings, and the actual text doesn't contradict it. (no ":)") T. - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
