Re: HTC TyTN || (P4550) violates GPL?? Or maybe Qualcomm itself with MSM7200???
On Dec 11, 2007 11:02 AM, Mauricio Mauad Menegaz Filho <[EMAIL PROTECTED]> wrote: > > Did phone packaging contain sources or written offer for them? If not, > > they are probably still violating GPL. gpl-violations.org, I'd say. > > Hi Michal/Pavel > > Both of you are right. Qualcomm is not offering source codes for the drivers > (at > least, there is no way to find the drivers on their site, and they > are probably not > asking for MSM based devices to advertise *drivers available* or such), nor > the > iguana source code contains the drivers. Licenses are needless until violated. > > Mauad If the drivers are on the L4 side, they would have no obligation to provide them. That's one of the reasons device manufacturers look at virtualized/micro-kernel architectures. Of course, if the device has Linux in it, they would still need to provide the sources for that, either in the product or via a written offer. scott -- scott preece -- 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/
Re: HTC TyTN || (P4550) violates GPL?? Or maybe Qualcomm itself with MSM7200???
On Dec 11, 2007 11:02 AM, Mauricio Mauad Menegaz Filho [EMAIL PROTECTED] wrote: Did phone packaging contain sources or written offer for them? If not, they are probably still violating GPL. gpl-violations.org, I'd say. Hi Michal/Pavel Both of you are right. Qualcomm is not offering source codes for the drivers (at least, there is no way to find the drivers on their site, and they are probably not asking for MSM based devices to advertise *drivers available* or such), nor the iguana source code contains the drivers. Licenses are needless until violated. Mauad If the drivers are on the L4 side, they would have no obligation to provide them. That's one of the reasons device manufacturers look at virtualized/micro-kernel architectures. Of course, if the device has Linux in it, they would still need to provide the sources for that, either in the product or via a written offer. scott -- scott preece -- 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/
Re: [PATCH] Spelling fix: lenght->length
On 11/4/07, Paulius Zaleckas <[EMAIL PROTECTED]> wrote:
I noticed a couple of additional typos, in the diff-provided material
near the patch.
> diff --git a/arch/ppc/syslib/ppc_sys.c b/arch/ppc/syslib/ppc_sys.c
> index 2d48018..837183c 100644
> --- a/arch/ppc/syslib/ppc_sys.c
> +++ b/arch/ppc/syslib/ppc_sys.c
> @@ -185,7 +185,7 @@ void platform_notify_map(const struct
> platform_notify_dev_map *map,
> */
>
> /*
> - Here we'll replace .name pointers with fixed-lenght strings
> + Here we'll replace .name pointers with fixed-length strings
> Hereby, this should be called *before* any func stuff triggeded.
---
Not your patch, but "triggeded" -> "triggered"; and I'm wondering what
the "Hereby"
is supposed to mean - seems like it might be meant to be "Therefore".
---
> */
> void ppc_sys_device_initfunc(void)
> diff --git a/drivers/media/video/pwc/pwc-if.c
> b/drivers/media/video/pwc/pwc-if.c
> index 7300ace..f991d72 100644
> --- a/drivers/media/video/pwc/pwc-if.c
> +++ b/drivers/media/video/pwc/pwc-if.c
> @@ -542,7 +542,7 @@ int pwc_handle_frame(struct pwc_device *pdev)
> }
>
> if (pdev->read_frame != NULL) {
> - /* Decompression is a lenghty process, so it's outside of the
> lock.
> + /* Decompression is a lengthy process, so it's outside of the
> lock.
>This gives the isoc_handler the opportunity to fill more
> frames
>in the mean time.
---
"mean time" -> "meantime"
---
> */
--
scott preece
-
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/
Re: [PATCH] Spelling fix: lenght-length
On 11/4/07, Paulius Zaleckas [EMAIL PROTECTED] wrote:
I noticed a couple of additional typos, in the diff-provided material
near the patch.
snip
diff --git a/arch/ppc/syslib/ppc_sys.c b/arch/ppc/syslib/ppc_sys.c
index 2d48018..837183c 100644
--- a/arch/ppc/syslib/ppc_sys.c
+++ b/arch/ppc/syslib/ppc_sys.c
@@ -185,7 +185,7 @@ void platform_notify_map(const struct
platform_notify_dev_map *map,
*/
/*
- Here we'll replace .name pointers with fixed-lenght strings
+ Here we'll replace .name pointers with fixed-length strings
Hereby, this should be called *before* any func stuff triggeded.
---
Not your patch, but triggeded - triggered; and I'm wondering what
the Hereby
is supposed to mean - seems like it might be meant to be Therefore.
---
*/
void ppc_sys_device_initfunc(void)
snip
diff --git a/drivers/media/video/pwc/pwc-if.c
b/drivers/media/video/pwc/pwc-if.c
index 7300ace..f991d72 100644
--- a/drivers/media/video/pwc/pwc-if.c
+++ b/drivers/media/video/pwc/pwc-if.c
@@ -542,7 +542,7 @@ int pwc_handle_frame(struct pwc_device *pdev)
}
if (pdev-read_frame != NULL) {
- /* Decompression is a lenghty process, so it's outside of the
lock.
+ /* Decompression is a lengthy process, so it's outside of the
lock.
This gives the isoc_handler the opportunity to fill more
frames
in the mean time.
---
mean time - meantime
---
*/
snip
--
scott preece
-
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/
Re: RFC: reviewer's statement of oversight
On 10/8/07, Jonathan Corbet <[EMAIL PROTECTED]> wrote: Some minor rewording suggestions: > + (b) Any problems, concerns, or questions relating to the patch have been > + communicated back to the submitter. I am satisfied with how the > + submitter has responded to my comments. --- Replace the last sentence with "I am satisfied with the submitter's response to my comments." or "The submitter has responded to my comments in a way that satisfied my concerns." --- > + > + (c) While there may (or may not) be things which could be improved with > + this submission, I believe that it is, at this time, (1) a worthwhile > + modification to the kernel, and (2) free of known issues which would > + argue against its inclusion. --- I would suggest dropping the "(or may not)" as unnecessary, and changing the "which would" to "that would". --- > + > + (d) While I have reviewed the patch and believe it to be sound, I can not --- >From a legal standpoint, "I do not" might be preferable to "I cannot", since it disclaims any intention to make such a statement, regardless of qualification. --- > + (unless explicitly stated elsewhere) make any warranties or guarantees > + that it will achieve its stated purpose or function properly in any > + given situation. > + > + (e) I understand and agree that this project and the contribution are > + public and that a record of the contribution (including my Reviewed-by > + tag and any associated public communications) is maintained > + indefinitely and may be redistributed consistent with this project or > + the open source license(s) involved. --- (e) seems over-careful, especially since you're applying it only to the Review-by tag, while all the other tags would also have the same concern. -- scott preece - 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/
Re: RFC: reviewer's statement of oversight
On 10/8/07, Jonathan Corbet [EMAIL PROTECTED] wrote: Some minor rewording suggestions: + (b) Any problems, concerns, or questions relating to the patch have been + communicated back to the submitter. I am satisfied with how the + submitter has responded to my comments. --- Replace the last sentence with I am satisfied with the submitter's response to my comments. or The submitter has responded to my comments in a way that satisfied my concerns. --- + + (c) While there may (or may not) be things which could be improved with + this submission, I believe that it is, at this time, (1) a worthwhile + modification to the kernel, and (2) free of known issues which would + argue against its inclusion. --- I would suggest dropping the (or may not) as unnecessary, and changing the which would to that would. --- + + (d) While I have reviewed the patch and believe it to be sound, I can not --- From a legal standpoint, I do not might be preferable to I cannot, since it disclaims any intention to make such a statement, regardless of qualification. --- + (unless explicitly stated elsewhere) make any warranties or guarantees + that it will achieve its stated purpose or function properly in any + given situation. + + (e) I understand and agree that this project and the contribution are + public and that a record of the contribution (including my Reviewed-by + tag and any associated public communications) is maintained + indefinitely and may be redistributed consistent with this project or + the open source license(s) involved. --- (e) seems over-careful, especially since you're applying it only to the Review-by tag, while all the other tags would also have the same concern. -- scott preece - 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/
Re: RFC: reviewer's statement of oversight
On 10/8/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote: > > On Oct 8 2007 19:37, Sam Ravnborg wrote: > >snip... > >Acked-by: > >Tested-by: > > * Used by random people to express their (dis)like/experience with the > patch. > > >Reviewed-by: > > * I am maintaner or an 'important' person and have had a > look at it in depth --- A couple of months ago there was a thread about Acked-by. At that time the consensus seemed to be that it was inappropriate for random people to add Acked-by - that it should only be added by people whose opinion was expected to a gate for merging. Did the Summit reach a decision that Acked-by was for anybody and Reviewed-by was for authorities? I like Randy's point - the assigning of weight to the Reviewer's opinion is necessarily in the hands of those at the top of the merge process and there's no need to ask reviewers to decide whether their opinion matters. In that view, "Acked-by" means "I have no objection to this patch, but don't claim deep review" and "Reviewed-by" means "I have no objection to this patch after a thorough review", and either can be attached by anybody who wants to express an opinion. scott -- scott preece - 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/
Re: RFC: reviewer's statement of oversight
On 10/8/07, J. Bruce Fields <[EMAIL PROTECTED]> wrote: > On Mon, Oct 08, 2007 at 08:34:47PM +0200, Stefan Richter wrote: ... > > So, putting a Tested-by into the changelog is only useful if the > > necessary testing is rather simple (i.e. "fixed the bug which I was > > always able to reproduce before") or if the tester is known to have > > performed rigorous and sufficiently broad tests. > > Well, you can still include those test-method details in the body of the > message in addition to adding the "Tested-by:". > > Does "Tested-by" just mean they ran some relevant test on the final > version of the patch? The really hard part is often the initial work > required to find a good reproduceable test case, capture the right error > report, or bisect to the right commit. I think that also counts as > "testing". And it'd be nice to have a tag for those sorts of > contributions, partly just as another way to ackowledge them. --- Tested-by should, at the very least, have a description of the test environment in the body (suggesting that the change compiled and ran in that environment). Preferably it should also have a description of the test or test suite run and whether that test failed on an unpatched system. scott -- scott preece - 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/
Re: RFC: reviewer's statement of oversight
On 10/8/07, J. Bruce Fields [EMAIL PROTECTED] wrote: On Mon, Oct 08, 2007 at 08:34:47PM +0200, Stefan Richter wrote: ... So, putting a Tested-by into the changelog is only useful if the necessary testing is rather simple (i.e. fixed the bug which I was always able to reproduce before) or if the tester is known to have performed rigorous and sufficiently broad tests. Well, you can still include those test-method details in the body of the message in addition to adding the Tested-by:. Does Tested-by just mean they ran some relevant test on the final version of the patch? The really hard part is often the initial work required to find a good reproduceable test case, capture the right error report, or bisect to the right commit. I think that also counts as testing. And it'd be nice to have a tag for those sorts of contributions, partly just as another way to ackowledge them. --- Tested-by should, at the very least, have a description of the test environment in the body (suggesting that the change compiled and ran in that environment). Preferably it should also have a description of the test or test suite run and whether that test failed on an unpatched system. scott -- scott preece - 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/
Re: RFC: reviewer's statement of oversight
On 10/8/07, Jan Engelhardt [EMAIL PROTECTED] wrote: On Oct 8 2007 19:37, Sam Ravnborg wrote: snip... Acked-by: Tested-by: * Used by random people to express their (dis)like/experience with the patch. Reviewed-by: * I am maintaner or an 'important' person and have had a look at it in depth --- A couple of months ago there was a thread about Acked-by. At that time the consensus seemed to be that it was inappropriate for random people to add Acked-by - that it should only be added by people whose opinion was expected to a gate for merging. Did the Summit reach a decision that Acked-by was for anybody and Reviewed-by was for authorities? I like Randy's point - the assigning of weight to the Reviewer's opinion is necessarily in the hands of those at the top of the merge process and there's no need to ask reviewers to decide whether their opinion matters. In that view, Acked-by means I have no objection to this patch, but don't claim deep review and Reviewed-by means I have no objection to this patch after a thorough review, and either can be attached by anybody who wants to express an opinion. scott -- scott preece - 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/
Re: [PATCH 1/3] CodingStyle updates
A couple of comments interspersed... On 9/28/07, Erez Zadok <[EMAIL PROTECTED]> wrote: ... > There are a number of driver model diagnostic macros in > which you should use to make sure messages are matched to the right device --- I think this "which" is non-restrictive, so it should have a comma after it (I realize that's not part of your patch). It's also possible to read it as restrictive, in which case "that" would be preferable. --- > and driver, and are tagged with the right level: dev_err(), dev_warn(), > -dev_info(), and so forth. For messages that aren't associated with a > -particular device, defines pr_debug() and pr_info(). > +dev_info(), and so forth. > + > +A number of people often like to define their own debugging printf's, --- "A number of people often like to..." is awkward. How about "Developers sometimes..." or "Too many people..." --- > +wrapping printk's in #ifdef's that get turned on only when subsystem > + Chapter 19: branch prediction optimizations > + > +The kernel includes macros called likely() and unlikely(), which can be used --- You might say "The kernel provides the macros likely()..." --- > +as hints to the compiler to optimize branch prediction. They operate by ... > +A good example of this is the above kmalloc(GFP_KERNEL) call. The chances > +of kmalloc() returning NULL are rather small, because even if it doesn't > +have memory to return to you at the moment, with GFP_KERNEL/__GFP_WAIT > +passed, kmalloc() will wait and suspend your thread, while it goes off to --- The commas after "passed" and "thread" is unnecessary. --- > +find some free memory (purging caches, flushing buffers, etc.). In other > +words, kmalloc() tries very hard to give you the memory you asked for by the > +time it return. --- "...by the time it return." should be "...by the time it returns." --- > + > +Consider the next, bad example. Suppose you're developing a file system > +which performs logically different actions on different types of entities: --- This "which" is restrictive; it would be preferable to use "that" instead. --- > +files, directories, symlinks, devices, etc. and you use this code: > + ... > +be penalized heavily for going [sic] down the wrong path... Therefore, you > +should consider also whether a seemingly-rare condition is indeed rare ALL --- The hyphen isn't necessary when the first word of the compount adjective is an adverb ending in "-ly", so, just "seemingly rare"; or switch to "apparently rare". --- > +the time. ... -- scott preece - 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/
Re: [PATCH 1/3] CodingStyle updates
A couple of comments interspersed... On 9/28/07, Erez Zadok [EMAIL PROTECTED] wrote: ... There are a number of driver model diagnostic macros in linux/device.h which you should use to make sure messages are matched to the right device --- I think this which is non-restrictive, so it should have a comma after it (I realize that's not part of your patch). It's also possible to read it as restrictive, in which case that would be preferable. --- and driver, and are tagged with the right level: dev_err(), dev_warn(), -dev_info(), and so forth. For messages that aren't associated with a -particular device, linux/kernel.h defines pr_debug() and pr_info(). +dev_info(), and so forth. + +A number of people often like to define their own debugging printf's, --- A number of people often like to... is awkward. How about Developers sometimes... or Too many people... --- +wrapping printk's in #ifdef's that get turned on only when subsystem + Chapter 19: branch prediction optimizations + +The kernel includes macros called likely() and unlikely(), which can be used --- You might say The kernel provides the macros likely()... --- +as hints to the compiler to optimize branch prediction. They operate by ... +A good example of this is the above kmalloc(GFP_KERNEL) call. The chances +of kmalloc() returning NULL are rather small, because even if it doesn't +have memory to return to you at the moment, with GFP_KERNEL/__GFP_WAIT +passed, kmalloc() will wait and suspend your thread, while it goes off to --- The commas after passed and thread is unnecessary. --- +find some free memory (purging caches, flushing buffers, etc.). In other +words, kmalloc() tries very hard to give you the memory you asked for by the +time it return. --- ...by the time it return. should be ...by the time it returns. --- + +Consider the next, bad example. Suppose you're developing a file system +which performs logically different actions on different types of entities: --- This which is restrictive; it would be preferable to use that instead. --- +files, directories, symlinks, devices, etc. and you use this code: + ... +be penalized heavily for going [sic] down the wrong path... Therefore, you +should consider also whether a seemingly-rare condition is indeed rare ALL --- The hyphen isn't necessary when the first word of the compount adjective is an adverb ending in -ly, so, just seemingly rare; or switch to apparently rare. --- +the time. ... -- scott preece - 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/
Re: [Celinux-dev] Re: [Announce] Linux-tiny project revival
- Original Message From: Tim Bird <[EMAIL PROTECTED]> Rob Landley wrote: Given that there are about 60,000 printks in the kernel (and that's not counting wrappers like dprintk() and other locally-defined functions and macros) it would be a huge task to examine the code and differentiate strings that really start a new log message (and thus should have an attached log level) and strings that don't. -- Tim --- So, if this is a good idea, maybe the new version with the separate argument should have a new name? Then you can mechanically convert the onces that fit the pattern to the new name and form and leave the others to clean up later. scott - 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/
Re: [Celinux-dev] Re: [Announce] Linux-tiny project revival
- Original Message From: Tim Bird [EMAIL PROTECTED] Rob Landley wrote: Given that there are about 60,000 printks in the kernel (and that's not counting wrappers like dprintk() and other locally-defined functions and macros) it would be a huge task to examine the code and differentiate strings that really start a new log message (and thus should have an attached log level) and strings that don't. -- Tim --- So, if this is a good idea, maybe the new version with the separate argument should have a new name? Then you can mechanically convert the onces that fit the pattern to the new name and form and leave the others to clean up later. scott - 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/
Re: [Announce] LessWatts.org power saving project
On 9/20/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote: > Intel's Open Source Technology Center is pleased to announce the > LessWatts.org project, an open source project for saving power on Linux. > > http://www.lesswatts.org > > > What is LessWatts.org about? > > > LessWatts.org is a place to bring users, developers and distribution > makers together around power reduction for linux machines, from mobile > to desktop to server to datacenter. LessWatts.org is about a > system-level approach to power savings, from the lowest level device > drivers in the kernel to the most advanced desktop applications. > LessWatts.org is about things you can do to reduce power usage. > LessWatts.org is about longer battery life, a lower airconditioning > bill, about reducing the impact of computers on the environment. > > LessWatts.org brings together a set of tips & tricks, tools, > technology development projects as well as documentation around power > saving. > > > Projects > > > At this time of launching the LessWatts.org project, the technology > development projects are those that Intel has started, is involved in > or has just started working on, such as PowerTOP, Tickless Idle, > Graphics and various link power management techniques. We'd like to > invite all developers and projects that focus on power saving to join > the LessWatts.org effort and community. > > > Arjan van de Ven > <[EMAIL PROTECTED]> > > http://www.lesswatts.org *sigh* Noble cause - dreadful name. And it's ungrammatical, too - should have been "FewerWatts" or "LessWattage". Or LessPower. Or it could have shared the Linux Foundations "GreenLinux" name. scott -- scott preece - 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/
Re: A little coding style nugget of joy
On 9/20/07, Robert P. J. Day <[EMAIL PROTECTED]> wrote: > On Thu, 20 Sep 2007, Pádraig Brady wrote: > > > Matt LaPlante wrote: > > > Since everyone loves random statistics, here are a few gems to give you a > > > break from your busy day: > > > > > > Number of lines in the 2.6.22 Linux kernel source that include one or > > > more trailing whitespaces: 135209 > > > Bytes saved by removing said whitespace: 151809 > > > Lines in the (unified) diff: 455437 > > > Size of the diff: 15M > > > People brave enough to submit the patch: ~0 > > > > It's gradually getting better so: > > http://lwn.net/2001/1129/a/whitespace.php3 > > and you wouldn't *believe* how much space you can save by getting rid > of all that annoying indentation. and don't even get me *started* on > those comments ... > > rday --- I think you're on to something here. If we stored the files with all the non-meaningful whitespace (including non-meaningful newlines) removed, not only would we save disk space, but we would also eliminate significant amounts of developer time and LKML bandwidth currently expended on arguing about formatting. Everybody could just run things through indent with whatever formatting they preferred. Might make diffs ugly, though... scott -- scott preece - 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/
Re: A little coding style nugget of joy
On 9/20/07, Robert P. J. Day [EMAIL PROTECTED] wrote: On Thu, 20 Sep 2007, Pádraig Brady wrote: Matt LaPlante wrote: Since everyone loves random statistics, here are a few gems to give you a break from your busy day: Number of lines in the 2.6.22 Linux kernel source that include one or more trailing whitespaces: 135209 Bytes saved by removing said whitespace: 151809 Lines in the (unified) diff: 455437 Size of the diff: 15M People brave enough to submit the patch: ~0 It's gradually getting better so: http://lwn.net/2001/1129/a/whitespace.php3 and you wouldn't *believe* how much space you can save by getting rid of all that annoying indentation. and don't even get me *started* on those comments ... rday --- I think you're on to something here. If we stored the files with all the non-meaningful whitespace (including non-meaningful newlines) removed, not only would we save disk space, but we would also eliminate significant amounts of developer time and LKML bandwidth currently expended on arguing about formatting. Everybody could just run things through indent with whatever formatting they preferred. Might make diffs ugly, though... scott -- scott preece - 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/
Re: [Announce] LessWatts.org power saving project
On 9/20/07, Arjan van de Ven [EMAIL PROTECTED] wrote: Intel's Open Source Technology Center is pleased to announce the LessWatts.org project, an open source project for saving power on Linux. http://www.lesswatts.org What is LessWatts.org about? LessWatts.org is a place to bring users, developers and distribution makers together around power reduction for linux machines, from mobile to desktop to server to datacenter. LessWatts.org is about a system-level approach to power savings, from the lowest level device drivers in the kernel to the most advanced desktop applications. LessWatts.org is about things you can do to reduce power usage. LessWatts.org is about longer battery life, a lower airconditioning bill, about reducing the impact of computers on the environment. LessWatts.org brings together a set of tips tricks, tools, technology development projects as well as documentation around power saving. Projects At this time of launching the LessWatts.org project, the technology development projects are those that Intel has started, is involved in or has just started working on, such as PowerTOP, Tickless Idle, Graphics and various link power management techniques. We'd like to invite all developers and projects that focus on power saving to join the LessWatts.org effort and community. Arjan van de Ven [EMAIL PROTECTED] http://www.lesswatts.org *sigh* Noble cause - dreadful name. And it's ungrammatical, too - should have been FewerWatts or LessWattage. Or LessPower. Or it could have shared the Linux Foundations GreenLinux name. scott -- scott preece - 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/
Re: Linux Foundation Technical Advisory Board Elections
On 8/22/07, James Bottomley <[EMAIL PROTECTED]> wrote: > The elections for five of the ten members of the Linux Foundation > Technical Advisory Board[TAB] are held every year, currently the > election will be at the 2007 Kernel Summit in a BOF session. > > Anyone is eligible to stand for election, simply send your nomination > to: > > [EMAIL PROTECTED] > ... Could you post the list of who the current members are and which ones hold the seats that are open this year? thanks, scott -- scott preece - 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/
Re: Linux Foundation Technical Advisory Board Elections
On 8/22/07, James Bottomley [EMAIL PROTECTED] wrote: The elections for five of the ten members of the Linux Foundation Technical Advisory Board[TAB] are held every year, currently the election will be at the 2007 Kernel Summit in a BOF session. Anyone is eligible to stand for election, simply send your nomination to: [EMAIL PROTECTED] ... Could you post the list of who the current members are and which ones hold the seats that are open this year? thanks, scott -- scott preece - 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/
Re: [PATCH try #3] security: Convert LSM into a static interface
On 7/19/07, Alan Cox <[EMAIL PROTECTED]> wrote: > Please distinguish between "cater to" and "support". If the kernel > didn't worry about supporting out-of-tree code, then why would there > be loadable module at all? Memory usage, flexibility, debugging. Module support was not added for external modules. Code that is being debugged is, often [usually, I hope], out-of-tree code, though it may be aimed at future inclusion. However, I do agree that there is value to having loadable modules for in-tree functionality, too. scott -- scott preece - 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/
Re: [PATCH try #3] security: Convert LSM into a static interface
On 7/19/07, James Morris <[EMAIL PROTECTED]> wrote: On Thu, 19 Jul 2007, Serge E. Hallyn wrote: > If we could get a few (non-afilliated :) people who work with > customers in the security field to tell us whether this is being > used, that would be very helpful. Not sure how to get that. The mainline kernel does not cater to out of tree code. Please distinguish between "cater to" and "support". If the kernel didn't worry about supporting out-of-tree code, then why would there be loadable module at all? Christian Ehrhardt already pointed to two reasons for loadable LSMs that are sufficient to justify keeping them - so you can replace them iteratively while you're developing them or choose between alternatives. Another twist is to use a tool to generate the module from a policy-definition file; this could be done at boot-time or could be done to replace the current policy on a running system (perhaps to add a new domain corresponding to a newly added service). Yes, this would need to be done with a lot of care, but part of providing mechanism (rather than policy) is enabling people to use the mechanism in the ways they prefer. scott -- scott preece - 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/
Re: [PATCH try #3] security: Convert LSM into a static interface
On 7/19/07, James Morris [EMAIL PROTECTED] wrote: On Thu, 19 Jul 2007, Serge E. Hallyn wrote: If we could get a few (non-afilliated :) people who work with customers in the security field to tell us whether this is being used, that would be very helpful. Not sure how to get that. The mainline kernel does not cater to out of tree code. Please distinguish between cater to and support. If the kernel didn't worry about supporting out-of-tree code, then why would there be loadable module at all? Christian Ehrhardt already pointed to two reasons for loadable LSMs that are sufficient to justify keeping them - so you can replace them iteratively while you're developing them or choose between alternatives. Another twist is to use a tool to generate the module from a policy-definition file; this could be done at boot-time or could be done to replace the current policy on a running system (perhaps to add a new domain corresponding to a newly added service). Yes, this would need to be done with a lot of care, but part of providing mechanism (rather than policy) is enabling people to use the mechanism in the ways they prefer. scott -- scott preece - 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/
Re: [PATCH try #3] security: Convert LSM into a static interface
On 7/19/07, Alan Cox [EMAIL PROTECTED] wrote: Please distinguish between cater to and support. If the kernel didn't worry about supporting out-of-tree code, then why would there be loadable module at all? Memory usage, flexibility, debugging. Module support was not added for external modules. Code that is being debugged is, often [usually, I hope], out-of-tree code, though it may be aimed at future inclusion. However, I do agree that there is value to having loadable modules for in-tree functionality, too. scott -- scott preece - 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/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On 6/19/07, Al Boldi <[EMAIL PROTECTED]> wrote: Nicolas Mailhot wrote: > > Tivo didn't make the Linux success. More Tivos can definitely undo it. > I don't think so. First, it's not Linux that made success, but rather GNU that uses Linux as its kernel. And, believe it or not, when people say Linux, they really mean GNU. People could care less what kernel they were running, as long as the system is up and runs the procs that offer their services. --- Actually, for use in devices (like TiVos or cell phones), it is very definitely the kernel that is of interest. Many such devices use little or no GNU software (some manufacturers have consciously avoided it because of the possibility of shifts like the GPLv3 changes). scott - 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/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On 6/19/07, Al Boldi [EMAIL PROTECTED] wrote: Nicolas Mailhot wrote: Tivo didn't make the Linux success. More Tivos can definitely undo it. I don't think so. First, it's not Linux that made success, but rather GNU that uses Linux as its kernel. And, believe it or not, when people say Linux, they really mean GNU. People could care less what kernel they were running, as long as the system is up and runs the procs that offer their services. --- Actually, for use in devices (like TiVos or cell phones), it is very definitely the kernel that is of interest. Many such devices use little or no GNU software (some manufacturers have consciously avoided it because of the possibility of shifts like the GPLv3 changes). scott - 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/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On 6/15/07, Tim Post <[EMAIL PROTECTED]> wrote: On Fri, 2007-06-15 at 19:52 -0500, Scott Preece wrote: > > Yes, but in highlighting the possibility of evil intentions you > distort the fact that usually there are no such evil intentions... > I don't think you can use "usually" and "fact" together like that. Why is it so bad to account for them since they (do) surface and (could) increase significantly in frequency? --- I agree that it is possible to have different definitions of "evil" and "ethical"... scott - 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/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On 6/15/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote: On Jun 15, 2007, "Scott Preece" <[EMAIL PROTECTED]> wrote: > Whether it's a legal requirement or a business decision, the result is > the same - neither forcing the manufacturer to make the device > non-updatable nor forcing the manufacturer to use different software > benefits anyone. I agree. But that's an incomplete picture. It's the other part of the picture, that you left out twice, that is the case that is good for the users *and* for the community. --- I don't think I "left it out". The point is that if the manufacturer is unwilling to give the right to modify, no change in the language is going to cause the user to have that right. scott - 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/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On 6/15/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote: On Jun 15, 2007, "Scott Preece" <[EMAIL PROTECTED]> wrote: > On 6/15/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote: >> > * Daniel Hazelton <[EMAIL PROTECTED]> wrote: >> >> That's correct, but with a catch: since the contract or license is >> chosen by the licensor, in case of ambiguity in the terms, many courts >> will interpret it in a way that privileges the licensee, regardless of >> the fact that copyright licenses are to be interpreted restrictively >> (at least in Brazilian law). And IANAL ;-) > --- > Hmm. In such a suit, however, the user would not be "the licensee" and > would not be a party to the suit - some author would be the plaintiff > and would be suing someone for doing something in violation of the > license that author granted - that is, the *defendant* would be the > licensee who would get the benefit of the doubt... Yes. And so justice is made. Licensor gets to pick the license, licensee gets the benefit of the doubt. What's the 'however' about? Was this not obvious? --- Sorry - I thought you were saying ambiguity would be resolved in favor of the user. If you meant in favor of the licensee (regardless of that limiting the user's rights), then I agree. scott - 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/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On 6/15/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote: On Jun 15, 2007, Ingo Molnar <[EMAIL PROTECTED]> wrote: How do these stop a user's exercise of the four freedoms of a piece of software licensed under the GPL? --- I know you don't see it that way, but I still find it bizarre that "the right to modify the software" should be construed as "implies the right to modify the device that the software was shipped in". I do agree that it's not a change in "spirit" - I'm sure the GPL authors would have disliked TiVoization 15 years ago as much as they do today, if they had thought about it (regardless of the Stallman interview where he said he didn't care very much about devices). However, whether it is a change "in spirit" or not, it clearly is a qualitative change that substantially changes the rights granted under the license and it's perfectly reasonable for some authors who liked the GPLv2 to dislike and reject GPLv3. scott - 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/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On 6/15/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote: > * Daniel Hazelton <[EMAIL PROTECTED]> wrote: That's correct, but with a catch: since the contract or license is chosen by the licensor, in case of ambiguity in the terms, many courts will interpret it in a way that privileges the licensee, regardless of the fact that copyright licenses are to be interpreted restrictively (at least in Brazilian law). And IANAL ;-) --- Hmm. In such a suit, however, the user would not be "the licensee" and would not be a party to the suit - some author would be the plaintiff and would be suing someone for doing something in violation of the license that author granted - that is, the *defendant* would be the licensee who would get the benefit of the doubt... scott - 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/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On 6/15/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote: On Jun 15, 2007, "Scott Preece" <[EMAIL PROTECTED]> wrote: >> That's not true. They can just as well throw the key away and refrain >> from modifying the installed software behind the users' back. > This characterization misses something important. For many product > devices, like cell phones, the modification is never "behind the > user's back" Okay, take out the "behind the users' back", it makes no difference. That was just to highlight the frequent evil intentions behind keeping the keys. --- Yes, but in highlighting the possibility of evil intentions you distort the fact that usually there are no such evil intentions... --- I wonder if giving half the key to the user and keeping the other half would be enough to satisfy the GPLv3 language while still enabling the vendor and user to update the software together. --- I think that's a possibility. I don't see how it's functionally different from the usual case where the manufacturer can't modify the device without the user's consent simply because the user has physical access to the device and the manufacturer doesn't. --- > The FSF's approval of this distinction (ROM versus replaceable) places > the FSF's particular principles over users interests, for no > particular reason Over *users* interest? How so? --- Users benefit from the ability to get software updates, from the manufacturer, to resolve problems, fix security vulnerabilities, and provide updated functionality. --- > if the manufacturer believes that it cannot legally allow software > modification, all the restriction does is force them either to make > the software unmodifiable (which advances freedom not at all) or to > use software under a different license (which advances freedom not > at all). Right. But if the manufacturer believes that it can legally allow it, and wants to be able to install, software modifications, then it must decide between giving that up and letting the user do it as well. And this is where the users interests may prevail. --- You're harping on the "cannot legally", which is fine but irrelevant. Whether it's a legal requirement or a business decision, the result is the same - neither forcing the manufacturer to make the device non-updatable nor forcing the manufacturer to use different software benefits anyone. I don't know of interesting cases where the manufacturer makes the device non-modifiable out of sheer bloody-mindedness. I don't believe that the existence of this clause will lead to more manufacturers making their devices modifiable - there are too many other options if they think that non-modifiability is important to them. [Note that I *do* think it's perfectly appropriate that authors who feel that they don't want their work used in such devices should be able to license them in line with that belief. I just don't think it has any practical value aside from making them feel better.] scott - 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/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On 6/15/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote: On Jun 15, 2007, Ingo Molnar <[EMAIL PROTECTED]> wrote: > it irreversibly cuts off certain people from being to distribute > GPLv3-ed software alongside with certain types of hardware that the > FSF's president does not like. That's not true. They can just as well throw the key away and refrain from modifying the installed software behind the users' back. --- This characterization misses something important. For many product devices, like cell phones, the modification is never "behind the user's back", but is done because the user has requested it (to fix a problem or add a new feature). If you go to ROM-based software, the user loses, because problems can't be fixed. For certain kinds of problems the user might be able to get a replacement device, but potentially involving losing any data stored on the device. The FSF's approval of this distinction (ROM versus replaceable) places the FSF's particular principles over users interests, for no particular reason - if the manufacturer believes that it cannot legally allow software modification, all the restriction does is force them either to make the software unmodifiable (which advances freedom not at all) or to use software under a different license (which advances freedom not at all). The result? The user STILL has no freedom to modify the software and the community around the software is diminished. To go back to the "behind your back" claim, the only cases I know where the software is replaced behind the users' back are cases were the updates are done by a service (usually not operated by the device manufacturer) that the user has voluntarily requested (like TiVo program guides or cable system subscriptions), which is generally a cases outside the scope of the license in any case. scott - 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/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On 6/15/07, Alexandre Oliva [EMAIL PROTECTED] wrote: On Jun 15, 2007, Ingo Molnar [EMAIL PROTECTED] wrote: it irreversibly cuts off certain people from being to distribute GPLv3-ed software alongside with certain types of hardware that the FSF's president does not like. That's not true. They can just as well throw the key away and refrain from modifying the installed software behind the users' back. --- This characterization misses something important. For many product devices, like cell phones, the modification is never behind the user's back, but is done because the user has requested it (to fix a problem or add a new feature). If you go to ROM-based software, the user loses, because problems can't be fixed. For certain kinds of problems the user might be able to get a replacement device, but potentially involving losing any data stored on the device. The FSF's approval of this distinction (ROM versus replaceable) places the FSF's particular principles over users interests, for no particular reason - if the manufacturer believes that it cannot legally allow software modification, all the restriction does is force them either to make the software unmodifiable (which advances freedom not at all) or to use software under a different license (which advances freedom not at all). The result? The user STILL has no freedom to modify the software and the community around the software is diminished. To go back to the behind your back claim, the only cases I know where the software is replaced behind the users' back are cases were the updates are done by a service (usually not operated by the device manufacturer) that the user has voluntarily requested (like TiVo program guides or cable system subscriptions), which is generally a cases outside the scope of the license in any case. scott - 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/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On 6/15/07, Alexandre Oliva [EMAIL PROTECTED] wrote: On Jun 15, 2007, Scott Preece [EMAIL PROTECTED] wrote: That's not true. They can just as well throw the key away and refrain from modifying the installed software behind the users' back. This characterization misses something important. For many product devices, like cell phones, the modification is never behind the user's back Okay, take out the behind the users' back, it makes no difference. That was just to highlight the frequent evil intentions behind keeping the keys. --- Yes, but in highlighting the possibility of evil intentions you distort the fact that usually there are no such evil intentions... --- I wonder if giving half the key to the user and keeping the other half would be enough to satisfy the GPLv3 language while still enabling the vendor and user to update the software together. --- I think that's a possibility. I don't see how it's functionally different from the usual case where the manufacturer can't modify the device without the user's consent simply because the user has physical access to the device and the manufacturer doesn't. --- The FSF's approval of this distinction (ROM versus replaceable) places the FSF's particular principles over users interests, for no particular reason Over *users* interest? How so? --- Users benefit from the ability to get software updates, from the manufacturer, to resolve problems, fix security vulnerabilities, and provide updated functionality. --- if the manufacturer believes that it cannot legally allow software modification, all the restriction does is force them either to make the software unmodifiable (which advances freedom not at all) or to use software under a different license (which advances freedom not at all). Right. But if the manufacturer believes that it can legally allow it, and wants to be able to install, software modifications, then it must decide between giving that up and letting the user do it as well. And this is where the users interests may prevail. --- You're harping on the cannot legally, which is fine but irrelevant. Whether it's a legal requirement or a business decision, the result is the same - neither forcing the manufacturer to make the device non-updatable nor forcing the manufacturer to use different software benefits anyone. I don't know of interesting cases where the manufacturer makes the device non-modifiable out of sheer bloody-mindedness. I don't believe that the existence of this clause will lead to more manufacturers making their devices modifiable - there are too many other options if they think that non-modifiability is important to them. [Note that I *do* think it's perfectly appropriate that authors who feel that they don't want their work used in such devices should be able to license them in line with that belief. I just don't think it has any practical value aside from making them feel better.] scott - 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/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On 6/15/07, Alexandre Oliva [EMAIL PROTECTED] wrote: * Daniel Hazelton [EMAIL PROTECTED] wrote: That's correct, but with a catch: since the contract or license is chosen by the licensor, in case of ambiguity in the terms, many courts will interpret it in a way that privileges the licensee, regardless of the fact that copyright licenses are to be interpreted restrictively (at least in Brazilian law). And IANAL ;-) --- Hmm. In such a suit, however, the user would not be the licensee and would not be a party to the suit - some author would be the plaintiff and would be suing someone for doing something in violation of the license that author granted - that is, the *defendant* would be the licensee who would get the benefit of the doubt... scott - 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/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On 6/15/07, Alexandre Oliva [EMAIL PROTECTED] wrote: On Jun 15, 2007, Ingo Molnar [EMAIL PROTECTED] wrote: How do these stop a user's exercise of the four freedoms of a piece of software licensed under the GPL? --- I know you don't see it that way, but I still find it bizarre that the right to modify the software should be construed as implies the right to modify the device that the software was shipped in. I do agree that it's not a change in spirit - I'm sure the GPL authors would have disliked TiVoization 15 years ago as much as they do today, if they had thought about it (regardless of the Stallman interview where he said he didn't care very much about devices). However, whether it is a change in spirit or not, it clearly is a qualitative change that substantially changes the rights granted under the license and it's perfectly reasonable for some authors who liked the GPLv2 to dislike and reject GPLv3. scott - 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/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On 6/15/07, Alexandre Oliva [EMAIL PROTECTED] wrote: On Jun 15, 2007, Scott Preece [EMAIL PROTECTED] wrote: On 6/15/07, Alexandre Oliva [EMAIL PROTECTED] wrote: * Daniel Hazelton [EMAIL PROTECTED] wrote: That's correct, but with a catch: since the contract or license is chosen by the licensor, in case of ambiguity in the terms, many courts will interpret it in a way that privileges the licensee, regardless of the fact that copyright licenses are to be interpreted restrictively (at least in Brazilian law). And IANAL ;-) --- Hmm. In such a suit, however, the user would not be the licensee and would not be a party to the suit - some author would be the plaintiff and would be suing someone for doing something in violation of the license that author granted - that is, the *defendant* would be the licensee who would get the benefit of the doubt... Yes. And so justice is made. Licensor gets to pick the license, licensee gets the benefit of the doubt. What's the 'however' about? Was this not obvious? --- Sorry - I thought you were saying ambiguity would be resolved in favor of the user. If you meant in favor of the licensee (regardless of that limiting the user's rights), then I agree. scott - 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/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On 6/15/07, Alexandre Oliva [EMAIL PROTECTED] wrote: On Jun 15, 2007, Scott Preece [EMAIL PROTECTED] wrote: Whether it's a legal requirement or a business decision, the result is the same - neither forcing the manufacturer to make the device non-updatable nor forcing the manufacturer to use different software benefits anyone. I agree. But that's an incomplete picture. It's the other part of the picture, that you left out twice, that is the case that is good for the users *and* for the community. --- I don't think I left it out. The point is that if the manufacturer is unwilling to give the right to modify, no change in the language is going to cause the user to have that right. scott - 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/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On 6/15/07, Tim Post [EMAIL PROTECTED] wrote: On Fri, 2007-06-15 at 19:52 -0500, Scott Preece wrote: Yes, but in highlighting the possibility of evil intentions you distort the fact that usually there are no such evil intentions... I don't think you can use usually and fact together like that. Why is it so bad to account for them since they (do) surface and (could) increase significantly in frequency? --- I agree that it is possible to have different definitions of evil and ethical... scott - 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/
Re: [PATCH (trivial)] Fix typo in Documentation/keys.txt
On 6/7/07, Satyam Sharma <[EMAIL PROTECTED]> wrote: Fix a typo in Documentation/keys.txt. Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]> Cc: David Howells <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] --- Documentation/keys.txt |5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) --- diff -ruNp a/Documentation/keys.txt b/Documentation/keys.txt --- a/Documentation/keys.txt2007-06-03 02:33:02.0 +0530 +++ b/Documentation/keys.txt2007-06-03 02:38:52.0 +0530 @@ -859,9 +859,8 @@ payload contents" for more information. void unregister_key_type(struct key_type *type); -Under some circumstances, it may be desirable to desirable to deal with a -bundle of keys. The facility provides access to the keyring type for managing -such a bundle: +Under some circumstances, it may be desirable to deal with a bundle of keys. +The facility provides access to the keyring type for managing such a bundle: --- It would improve the latter sentence to either delete "access to" or else change "provides access to" to "defines. scott - 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/
Re: [PATCH (trivial)] Fix typo in Documentation/keys.txt
On 6/7/07, Satyam Sharma [EMAIL PROTECTED] wrote: Fix a typo in Documentation/keys.txt. Signed-off-by: Satyam Sharma [EMAIL PROTECTED] Cc: David Howells [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] --- Documentation/keys.txt |5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) --- diff -ruNp a/Documentation/keys.txt b/Documentation/keys.txt --- a/Documentation/keys.txt2007-06-03 02:33:02.0 +0530 +++ b/Documentation/keys.txt2007-06-03 02:38:52.0 +0530 @@ -859,9 +859,8 @@ payload contents for more information. void unregister_key_type(struct key_type *type); -Under some circumstances, it may be desirable to desirable to deal with a -bundle of keys. The facility provides access to the keyring type for managing -such a bundle: +Under some circumstances, it may be desirable to deal with a bundle of keys. +The facility provides access to the keyring type for managing such a bundle: --- It would improve the latter sentence to either delete access to or else change provides access to to defines. scott - 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/
Re: [patch 1/1] document Acked-by:
On 6/2/07, Andrew Morton <[EMAIL PROTECTED]> wrote: On Sat, 2 Jun 2007 21:06:14 -0700 Randy Dunlap <[EMAIL PROTECTED]> wrote: > On Sat, 2 Jun 2007 19:57:41 -0700 Scott Preece wrote: > > > On 6/2/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > ... > > > +The Signed-off-by: tag implies that the signer was involved in the development > > --- > > > > Change "implies" to "indicates" - it's an explicit statement, not an > > implication. > > > > --- > > > +of the patch, or that he/she was in the patch's delivery path. > > > + > > > +If a person was not directly involved in the preparation or handling of a > > > +patch but wishes to signify and record their approval of it then they can > > > +arrange to have an Acked-by: line added to the patch's changelog. > > > + > > > +Acked-by: is often used by the maintainer of the affected code when that > > > +maintainer neither contributed to nor forwarded the patch themselves. > > --- > > > > This using plural pronouns for indefinite gender leaves one in vague > > territory, but I think "themself" would be better than "themselves, > > since "maintainer" is singular. > > ugh. :( > not-acked-by: /me > I just deleted it ;) "neither contributed to nor forwarded the patch." --- Wise as usual - much better! scott - 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/
Re: [patch 1/1] document Acked-by:
On 6/2/07, Andrew Morton [EMAIL PROTECTED] wrote: On Sat, 2 Jun 2007 21:06:14 -0700 Randy Dunlap [EMAIL PROTECTED] wrote: On Sat, 2 Jun 2007 19:57:41 -0700 Scott Preece wrote: On 6/2/07, Andrew Morton [EMAIL PROTECTED] wrote: ... +The Signed-off-by: tag implies that the signer was involved in the development --- Change implies to indicates - it's an explicit statement, not an implication. --- +of the patch, or that he/she was in the patch's delivery path. + +If a person was not directly involved in the preparation or handling of a +patch but wishes to signify and record their approval of it then they can +arrange to have an Acked-by: line added to the patch's changelog. + +Acked-by: is often used by the maintainer of the affected code when that +maintainer neither contributed to nor forwarded the patch themselves. --- This using plural pronouns for indefinite gender leaves one in vague territory, but I think themself would be better than themselves, since maintainer is singular. ugh. :( not-acked-by: /me I just deleted it ;) neither contributed to nor forwarded the patch. --- Wise as usual - much better! scott - 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/
Re: [patch 1/1] document Acked-by:
On 6/2/07, Andrew Morton <[EMAIL PROTECTED]> wrote: ... +The Signed-off-by: tag implies that the signer was involved in the development --- Change "implies" to "indicates" - it's an explicit statement, not an implication. --- +of the patch, or that he/she was in the patch's delivery path. + +If a person was not directly involved in the preparation or handling of a +patch but wishes to signify and record their approval of it then they can +arrange to have an Acked-by: line added to the patch's changelog. + +Acked-by: is often used by the maintainer of the affected code when that +maintainer neither contributed to nor forwarded the patch themselves. --- This using plural pronouns for indefinite gender leaves one in vague territory, but I think "themself" would be better than "themselves, since "maintainer" is singular. --- + +Acked-by: is not as formal as Signed-off-by:. It is a record that the acker +has at least reviewed the patch and has indicated acceptance. Hence patch +mergers will sometimes manually covert an acker's "yep, looks good to me" into --- "covert" -> "convert" --- +an Acked-by:. + +Acked-by: does not necessarily indicate acknowledgement of the entire patch. +For example, if a patch affects multiple subsystems and has an Acked-by: from +one subsystem maintainer then this usually indicates acknowledgement of just +the part which affects that maintainer's code. Judgement should be used here. +When in doubt people should refer to the original discussion in the mailing +list archives. + + +14) The canonical patch format The canonical patch subject line is: - 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/
Re: [patch 1/1] document Acked-by:
On 6/2/07, Andrew Morton [EMAIL PROTECTED] wrote: ... +The Signed-off-by: tag implies that the signer was involved in the development --- Change implies to indicates - it's an explicit statement, not an implication. --- +of the patch, or that he/she was in the patch's delivery path. + +If a person was not directly involved in the preparation or handling of a +patch but wishes to signify and record their approval of it then they can +arrange to have an Acked-by: line added to the patch's changelog. + +Acked-by: is often used by the maintainer of the affected code when that +maintainer neither contributed to nor forwarded the patch themselves. --- This using plural pronouns for indefinite gender leaves one in vague territory, but I think themself would be better than themselves, since maintainer is singular. --- + +Acked-by: is not as formal as Signed-off-by:. It is a record that the acker +has at least reviewed the patch and has indicated acceptance. Hence patch +mergers will sometimes manually covert an acker's yep, looks good to me into --- covert - convert --- +an Acked-by:. + +Acked-by: does not necessarily indicate acknowledgement of the entire patch. +For example, if a patch affects multiple subsystems and has an Acked-by: from +one subsystem maintainer then this usually indicates acknowledgement of just +the part which affects that maintainer's code. Judgement should be used here. +When in doubt people should refer to the original discussion in the mailing +list archives. + + +14) The canonical patch format The canonical patch subject line is: - 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/
Re: [patch 1/1] document Acked-by:
On 6/1/07, Krzysztof Halasa <[EMAIL PROTECTED]> wrote: "John Anthony Kazos Jr." <[EMAIL PROTECTED]> writes: > Indeed. Acked-by: implies authority, and only very few people should be > able to do it. Namely, the only person who can ACK a patch is a person who > could also NACK a patch and expect it to actually be dropped. If I think a > patch is bad, I can say so, but as I have no authority, my statement would > be taken on merit alone, whereas Linus or Andrew or such could just NACK > it and move on without having to spew a blurb every time. Everyone always has some authority so everyone can ack or nack any patch and I hope the action taken will always depend on merit rather than person, especially if it's a technical issue and not some style etc. thing. -- Krzysztof Halasa --- This is a question worth answering - is it rude to ack/nak a patch if you're not a maintainer or otherwise known-to-be-trusted, or is it OK for anyone to express an opinion? Andrew's patch text seems to imply that it's generally OK. scott - 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/
Re: [patch 1/1] document Acked-by:
On 6/1/07, Krzysztof Halasa [EMAIL PROTECTED] wrote: John Anthony Kazos Jr. [EMAIL PROTECTED] writes: Indeed. Acked-by: implies authority, and only very few people should be able to do it. Namely, the only person who can ACK a patch is a person who could also NACK a patch and expect it to actually be dropped. If I think a patch is bad, I can say so, but as I have no authority, my statement would be taken on merit alone, whereas Linus or Andrew or such could just NACK it and move on without having to spew a blurb every time. Everyone always has some authority so everyone can ack or nack any patch and I hope the action taken will always depend on merit rather than person, especially if it's a technical issue and not some style etc. thing. -- Krzysztof Halasa --- This is a question worth answering - is it rude to ack/nak a patch if you're not a maintainer or otherwise known-to-be-trusted, or is it OK for anyone to express an opinion? Andrew's patch text seems to imply that it's generally OK. scott - 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/
Re: [PATCH] [condingstyle] Add chapter on tests
On 5/26/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote: Based in part on Auke's patch. Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]> --- Documentation/CodingStyle | 74 +++--- 1 file changed, 64 insertions(+), 10 deletions(-) Index: linux-2.6.22-rc3/Documentation/CodingStyle === --- linux-2.6.22-rc3.orig/Documentation/CodingStyle +++ linux-2.6.22-rc3/Documentation/CodingStyle @@ -407,7 +407,61 @@ out: return result; } - Chapter 8: Commenting + Chapyer 8: Tests --- Fix the "Chapyer" spelling above. However, I think this set of rules is not universally agreed to and probably should not be added at this time. I'm not convinced that it makes the code more readable. scott - 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/
Re: [PATCH] [condingstyle] Add chapter on tests
On 5/26/07, Jan Engelhardt [EMAIL PROTECTED] wrote: Based in part on Auke's patch. Signed-off-by: Jan Engelhardt [EMAIL PROTECTED] --- Documentation/CodingStyle | 74 +++--- 1 file changed, 64 insertions(+), 10 deletions(-) Index: linux-2.6.22-rc3/Documentation/CodingStyle === --- linux-2.6.22-rc3.orig/Documentation/CodingStyle +++ linux-2.6.22-rc3/Documentation/CodingStyle @@ -407,7 +407,61 @@ out: return result; } - Chapter 8: Commenting + Chapyer 8: Tests --- Fix the Chapyer spelling above. However, I think this set of rules is not universally agreed to and probably should not be added at this time. I'm not convinced that it makes the code more readable. scott - 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/
Re: [PATCH - 1/1] Documentation/HOWTO
On 5/18/07, Bernd Eckenfels <[EMAIL PROTECTED]> wrote: In article <[EMAIL PROTECTED]> you wrote: >> bugs is one of the best ways to get merits among other developers, because >> not many people like wasting time fixing other people's bugs. > ^^^ > > you might want to find a less demeaning term for debugging than --- I'm pretty sure an economist would describe debugging as wasted time (non-value-add). The point being, of course, that the original coder's mistakes caused someone else to have to waste time, time that could otherwise have been spent adding value, fixing the problem. However, it might be phrased more diplomatically in this context, like "because you are sacrificing time that could be spent adding features, to fix somebody else's mistakes". scott - 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/
Re: [PATCH - 1/1] Documentation/HOWTO
On 5/18/07, Bernd Eckenfels [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED] you wrote: bugs is one of the best ways to get merits among other developers, because not many people like wasting time fixing other people's bugs. ^^^ you might want to find a less demeaning term for debugging than --- I'm pretty sure an economist would describe debugging as wasted time (non-value-add). The point being, of course, that the original coder's mistakes caused someone else to have to waste time, time that could otherwise have been spent adding value, fixing the problem. However, it might be phrased more diplomatically in this context, like because you are sacrificing time that could be spent adding features, to fix somebody else's mistakes. scott - 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/
Re: [Fwd: Re: Google are using linux kernel - what do you know about the source?]
On 5/23/07, Jeff Garzik <[EMAIL PROTECTED]> wrote: Alan Cox wrote: >> Google does not distribute their software, so they do not have to make >> their modifications public. > > They do for the kernel - they produce an "appliance". Ah, I stand corrected. >> WRT the Linux kernel, Google is essentially a closed source company. > > They've quietly fed little bits back now and then but not made a big song > and dance about it. Hopefully with Andrew there and the like more will > occur. Strange that the NIC and SATA driver bits never seem to be among those "little bits"... Along with filesystem and other modifications discussed in the press, or observable net stack behavior when connecting to their computers over the 'net. So, emphasis on "little", I guess. Jeff --- For 2.6.21, Jon Corbet's count for LWN showed Google ninth on the list (by number of changesets), among companies whose contributors could be identified. - 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/
Re: [Fwd: Re: Google are using linux kernel - what do you know about the source?]
On 5/23/07, Jeff Garzik [EMAIL PROTECTED] wrote: Alan Cox wrote: Google does not distribute their software, so they do not have to make their modifications public. They do for the kernel - they produce an appliance. Ah, I stand corrected. WRT the Linux kernel, Google is essentially a closed source company. They've quietly fed little bits back now and then but not made a big song and dance about it. Hopefully with Andrew there and the like more will occur. Strange that the NIC and SATA driver bits never seem to be among those little bits... Along with filesystem and other modifications discussed in the press, or observable net stack behavior when connecting to their computers over the 'net. So, emphasis on little, I guess. Jeff --- For 2.6.21, Jon Corbet's count for LWN showed Google ninth on the list (by number of changesets), among companies whose contributors could be identified. - 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/
Re: [PATCH] Documentation/memory-barriers.txt: various fixes
On 5/21/07, Jarek Poplawski <[EMAIL PROTECTED]> wrote: On Mon, May 21, 2007 at 03:12:07PM +0100, David Howells wrote: > Jarek Poplawski <[EMAIL PROTECTED]> wrote: > > > > > - load will be directed), a data dependency barrier would be required to > > > > + load will be directed), the data dependency barrier would be required to > > > > > > I think that should be "a". > > > > I could only guess (it's a magic to me) - so, if it doesn't matter > > "A data ..." begins this paragraph... > > I see what you mean. I see it as "a data dependency barrier ..." though. That > may be because I wrote the doc, however. I wonder if "data dependency" should > be hyphenated to make it clearer. What do you think? Better don't ask. Now I'm far less decided, than yesterday. --- "data-dependency barrier" would be better, assuming you mean a barrier enforcing a data dependency. If you say "data dependency barrier" you could also mean a "dependency barrier" implemented as a piece of data, for instance, like a flag value in a data stream that forces synchronization with another data stream. scott - 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/
Re: [PATCH] Documentation/memory-barriers.txt: various fixes
On 5/21/07, Jarek Poplawski [EMAIL PROTECTED] wrote: On Mon, May 21, 2007 at 03:12:07PM +0100, David Howells wrote: Jarek Poplawski [EMAIL PROTECTED] wrote: - load will be directed), a data dependency barrier would be required to + load will be directed), the data dependency barrier would be required to I think that should be a. I could only guess (it's a magic to me) - so, if it doesn't matter A data ... begins this paragraph... I see what you mean. I see it as a data dependency barrier ... though. That may be because I wrote the doc, however. I wonder if data dependency should be hyphenated to make it clearer. What do you think? Better don't ask. Now I'm far less decided, than yesterday. --- data-dependency barrier would be better, assuming you mean a barrier enforcing a data dependency. If you say data dependency barrier you could also mean a dependency barrier implemented as a piece of data, for instance, like a flag value in a data stream that forces synchronization with another data stream. scott - 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/
Re: [patch 07/10] Linux Kernel Markers - Documentation
Hi, Here is a patch to marker.txt to make the English read a little better. I didn't change the references to out-of-tree packages. @@ -3,33 +3,30 @@ Mathieu Desnoyers - This document introduces to markers and discusses its purpose. It -shows some usage examples of the Linux Kernel Markers : how to insert markers -within the kernel and how to connect probes to a marker. Finally, it has some -probe module examples. This is what connects to a marker. - +This document introduces Linux Kernel Markers and their use. It provides +examples of how to insert markers in the kernel and connect probe functions to +them and provides some examples of probe functions. * Purpose of markers -A marker placed in your code provides a hook to a function (probe) that +A marker placed in your code provides a hook to call a function (probe) that you can provide at runtime. A marker can be "on" (a probe is connected to it) -or "off" (no probe is attached). An "off" marker has no effect. When turned on, -the function you provide is called each time the marker is executed in the -execution context of the caller. When the function provided ends its execution, -it returns to the caller (marker site). +or "off" (no probe is attached). When a marker is "off" it has no +effect. When a marker is "on", the function you provide is called each +time the marker is executed, in the execution context of the +caller. When the function provided ends its execution, it returns to the +caller (continuing from the marker site). -You can put markers at important locations in the code. They act as +You can put markers at important locations in the code. Markers are lightweight hooks that can pass an arbitrary number of parameters, -described in a printk-like format string, to a function whenever the marker -code is reached. +described in a printk-like format string, to the attached probe function. -They can be used for tracing (LTTng, LKET over SystemTAP), overall performance -accounting (SystemTAP). They could also be used to implement -efficient hooks for SELinux or any other subsystem that would have this -kind of need. +Markers can be used for tracing (LTTng, LKET over SystemTAP), overall +performance accounting (SystemTAP), or to hook to monitoring +subsystems (like SELinux) that need to observe kernel behavior. -Using the markers for system audit (SELinux) would require to pass a -variable by address that would be later checked by the marked routine. +Using the markers for system audit (SELinux) would require passing a +variable by address so that it could be checked by the marked routine. * Usage @@ -52,15 +49,15 @@ Where : Connecting a function (probe) to a marker is done by providing a probe (function to call) for the specific marker through marker_set_probe(). It will automatically connect the function and enable the marker site. Removing a probe -is done through marker_remove_probe(). Probe removal is preempt safe because +is done through marker_remove_probe(). Probe removal is preempt-safe because preemption is disabled around the probe call. See the "Probe example" section below for a sample probe module. -The marker mechanism supports multiple instances of the same marker. -Markers can be put in inline functions, inlined static functions and +The marker mechanism supports inserting multiple instances of the same marker. +Markers can be put in inline functions, inlined static functions, and unrolled loops. -Note : It is safe to put markers within preempt-safe code : preempt_enable() +Note: It is safe to put markers within preempt-safe code : preempt_enable() will not call the scheduler due to the tests in preempt_schedule(). @@ -68,23 +65,23 @@ will not call the scheduler due to the t You will find, in asm-*/marker.h, optimisations for given architectures (currently i386 and powerpc). They use a load immediate instead of a data load, -which saves a data cache hit, but also requires cross CPU code modification. In -order to support embedded systems which use read-only memory for their code, the +which saves a data cache hit, but also requires cross-CPU code modification. In +order to support embedded systems that use read-only memory for their code, the optimization can be disabled through menu options. The MF_* flags can be used to control the type of marker. See the include/marker.h header for the list of flags. They can be specified as the -first parameter of the _trace_mark() macro, such as the following example which +first parameter of the _trace_mark() macro, as in the following example, which is safe with respect to lockdep.c (useful for marking lockdep.c and printk functions). _trace_mark(MF_DEFAULT | ~MF_LOCKDEP, subsystem_eventb, MARK_NOARGS); -Another example is to specify that a specific marker must never call printk : +Another example is to specify that a specific marker must never call printk: _trace_mark(MF_DEFAULT | ~MF_PRINTK, subsystem_eventc, "%d %s", someint,
Re: [patch 07/10] Linux Kernel Markers - Documentation
Hi, Here is a patch to marker.txt to make the English read a little better. I didn't change the references to out-of-tree packages. @@ -3,33 +3,30 @@ Mathieu Desnoyers - This document introduces to markers and discusses its purpose. It -shows some usage examples of the Linux Kernel Markers : how to insert markers -within the kernel and how to connect probes to a marker. Finally, it has some -probe module examples. This is what connects to a marker. - +This document introduces Linux Kernel Markers and their use. It provides +examples of how to insert markers in the kernel and connect probe functions to +them and provides some examples of probe functions. * Purpose of markers -A marker placed in your code provides a hook to a function (probe) that +A marker placed in your code provides a hook to call a function (probe) that you can provide at runtime. A marker can be on (a probe is connected to it) -or off (no probe is attached). An off marker has no effect. When turned on, -the function you provide is called each time the marker is executed in the -execution context of the caller. When the function provided ends its execution, -it returns to the caller (marker site). +or off (no probe is attached). When a marker is off it has no +effect. When a marker is on, the function you provide is called each +time the marker is executed, in the execution context of the +caller. When the function provided ends its execution, it returns to the +caller (continuing from the marker site). -You can put markers at important locations in the code. They act as +You can put markers at important locations in the code. Markers are lightweight hooks that can pass an arbitrary number of parameters, -described in a printk-like format string, to a function whenever the marker -code is reached. +described in a printk-like format string, to the attached probe function. -They can be used for tracing (LTTng, LKET over SystemTAP), overall performance -accounting (SystemTAP). They could also be used to implement -efficient hooks for SELinux or any other subsystem that would have this -kind of need. +Markers can be used for tracing (LTTng, LKET over SystemTAP), overall +performance accounting (SystemTAP), or to hook to monitoring +subsystems (like SELinux) that need to observe kernel behavior. -Using the markers for system audit (SELinux) would require to pass a -variable by address that would be later checked by the marked routine. +Using the markers for system audit (SELinux) would require passing a +variable by address so that it could be checked by the marked routine. * Usage @@ -52,15 +49,15 @@ Where : Connecting a function (probe) to a marker is done by providing a probe (function to call) for the specific marker through marker_set_probe(). It will automatically connect the function and enable the marker site. Removing a probe -is done through marker_remove_probe(). Probe removal is preempt safe because +is done through marker_remove_probe(). Probe removal is preempt-safe because preemption is disabled around the probe call. See the Probe example section below for a sample probe module. -The marker mechanism supports multiple instances of the same marker. -Markers can be put in inline functions, inlined static functions and +The marker mechanism supports inserting multiple instances of the same marker. +Markers can be put in inline functions, inlined static functions, and unrolled loops. -Note : It is safe to put markers within preempt-safe code : preempt_enable() +Note: It is safe to put markers within preempt-safe code : preempt_enable() will not call the scheduler due to the tests in preempt_schedule(). @@ -68,23 +65,23 @@ will not call the scheduler due to the t You will find, in asm-*/marker.h, optimisations for given architectures (currently i386 and powerpc). They use a load immediate instead of a data load, -which saves a data cache hit, but also requires cross CPU code modification. In -order to support embedded systems which use read-only memory for their code, the +which saves a data cache hit, but also requires cross-CPU code modification. In +order to support embedded systems that use read-only memory for their code, the optimization can be disabled through menu options. The MF_* flags can be used to control the type of marker. See the include/marker.h header for the list of flags. They can be specified as the -first parameter of the _trace_mark() macro, such as the following example which +first parameter of the _trace_mark() macro, as in the following example, which is safe with respect to lockdep.c (useful for marking lockdep.c and printk functions). _trace_mark(MF_DEFAULT | ~MF_LOCKDEP, subsystem_eventb, MARK_NOARGS); -Another example is to specify that a specific marker must never call printk : +Another example is to specify that a specific marker must never call printk: _trace_mark(MF_DEFAULT | ~MF_PRINTK, subsystem_eventc, %d %s, someint, somestring,); -Flag
Re: [PATCH] "volatile considered harmful" document
On 5/9/07, Jonathan Corbet <[EMAIL PROTECTED]> wrote: OK, here's an updated version of the volatile document - as a plain text file this time. It drops a new file in Documentation/, but might it be better as an addition to CodingStyle? ... --- I think the size of this file is OK as a separate file, but much too big for CodingStyle. It would be good to also write a pithy paragraph to go into CodingStyle to convey the rule and point at this file. scott - 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/
Re: [PATCH] volatile considered harmful document
On 5/9/07, Jonathan Corbet [EMAIL PROTECTED] wrote: OK, here's an updated version of the volatile document - as a plain text file this time. It drops a new file in Documentation/, but might it be better as an addition to CodingStyle? ... --- I think the size of this file is OK as a separate file, but much too big for CodingStyle. It would be good to also write a pithy paragraph to go into CodingStyle to convey the rule and point at this file. scott - 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/
Re: condingstyle, was Re: utrace comments
On 5/1/07, Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
On Tue, 1 May 2007, Satyam Sharma wrote:
> Actually, the latter style (one condition per line and the && or ||
> operators appearing _before_ the conditions in subsequent lines)
> is quite popular for multi-line compound conditions (well, I've seen this
> in kernel/workqueue.c, kernel/stop_machine.c, etc at least, and also in
> Linus' code, if I'm not mistaken). We also align subsequent lines to the
> column of the condition belonging to the same "logical level" on the
> previous line using _spaces_ (note that this is alignment, not indentation,
> using spaces). The rationale is to make the operator prominent and thus make
> the structure of a complex multi-line compound conditional expression more
> readable and obvious at first glance itself. For example, consider:
>
> if (veryverylengthycondition1 &&
> smallcond2 &&
> (conditionnumber3a ||
> condition3b)) {
> ...
> }
>
> versus
>
> if (veryverylengthycondition1
> && smallcond2
> && (conditionnumber3a
> || condition3b)) {
> ...
> }
>
> ?
>
> Latter wins, doesn't it?
... because you forgot to align subsequent lines to the column of the
condition belonging to the same "logical level" on the previous line.
Consider this:
if (veryverylengthycondition1 &&
smallcond2 &&
(conditionnumber3a ||
condition3b)) {
...
}
Gr{oetje,eeting}s,
Geert
I still find the leading-operator style much more readable. The most
important thing in reading a long, complex conditional is
understanding the structure of the operators, not the operands.
Putting the operators at the front of the line emphasizes that
structure, especially since you can line the operators up to match the
logical indenting, whereas the trailing-operator style leaves the
operators scattered and hard to assemble into a logical structure.
However, there's a lot of difference of opinion on this (perhaps
rooted in differences in cognition and reading behavior). For me it's
not even close - expressions broken so the operators are at the head
of the line snap into focus and those with operators at the ends of
the lines look like undifferentiated goo. Since some of the style
guides I've seen do it the other way, I assume some people have the
opposite perception. I guess that's why indent offers options for
doing it either way...
scott
-
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/
Re: condingstyle, was Re: utrace comments
On 5/1/07, Geert Uytterhoeven [EMAIL PROTECTED] wrote:
On Tue, 1 May 2007, Satyam Sharma wrote:
Actually, the latter style (one condition per line and the or ||
operators appearing _before_ the conditions in subsequent lines)
is quite popular for multi-line compound conditions (well, I've seen this
in kernel/workqueue.c, kernel/stop_machine.c, etc at least, and also in
Linus' code, if I'm not mistaken). We also align subsequent lines to the
column of the condition belonging to the same logical level on the
previous line using _spaces_ (note that this is alignment, not indentation,
using spaces). The rationale is to make the operator prominent and thus make
the structure of a complex multi-line compound conditional expression more
readable and obvious at first glance itself. For example, consider:
if (veryverylengthycondition1
smallcond2
(conditionnumber3a ||
condition3b)) {
...
}
versus
if (veryverylengthycondition1
smallcond2
(conditionnumber3a
|| condition3b)) {
...
}
?
Latter wins, doesn't it?
... because you forgot to align subsequent lines to the column of the
condition belonging to the same logical level on the previous line.
Consider this:
if (veryverylengthycondition1
smallcond2
(conditionnumber3a ||
condition3b)) {
...
}
Gr{oetje,eeting}s,
Geert
I still find the leading-operator style much more readable. The most
important thing in reading a long, complex conditional is
understanding the structure of the operators, not the operands.
Putting the operators at the front of the line emphasizes that
structure, especially since you can line the operators up to match the
logical indenting, whereas the trailing-operator style leaves the
operators scattered and hard to assemble into a logical structure.
However, there's a lot of difference of opinion on this (perhaps
rooted in differences in cognition and reading behavior). For me it's
not even close - expressions broken so the operators are at the head
of the line snap into focus and those with operators at the ends of
the lines look like undifferentiated goo. Since some of the style
guides I've seen do it the other way, I assume some people have the
opposite perception. I guess that's why indent offers options for
doing it either way...
scott
-
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/
Re: coding style for long conditions
On 4/6/07, Roland Dreier <[EMAIL PROTECTED]> wrote:
[I can't believe I'm stepping into an indentation flamewar, but here goes...]
that the line with "bar" on it is properly indented with one tab
(since it is part of the if statement that is also indented one tab),
and then four spaces are used to align the "bar" with the previous
line. So only tabs are used for indentation, and the spaces after the
tab are used for alignment, and the letter of the law is observed.
If you have a git tree handy, you can do "git show 68380b58" and see
that Linus himself wrote:
if (get_wq_data(work) == cwq
&& work_pending(work)
&& !list_empty(>entry)) {
---
I'm happy to see Linus did it exactly the way I would have...
So, perhaps the rule in CodingStyle should be clarified to say that
indentation is used to show nesting depth and always expressed in TAB
characters, but additional spacing may be used following the
structural TABs to appropriately format continuation lines...
scott
-
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/
Re: coding style for long conditions
On 4/6/07, Roland Dreier [EMAIL PROTECTED] wrote:
[I can't believe I'm stepping into an indentation flamewar, but here goes...]
that the line with bar on it is properly indented with one tab
(since it is part of the if statement that is also indented one tab),
and then four spaces are used to align the bar with the previous
line. So only tabs are used for indentation, and the spaces after the
tab are used for alignment, and the letter of the law is observed.
If you have a git tree handy, you can do git show 68380b58 and see
that Linus himself wrote:
if (get_wq_data(work) == cwq
work_pending(work)
!list_empty(work-entry)) {
---
I'm happy to see Linus did it exactly the way I would have...
So, perhaps the rule in CodingStyle should be clarified to say that
indentation is used to show nesting depth and always expressed in TAB
characters, but additional spacing may be used following the
structural TABs to appropriately format continuation lines...
scott
-
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/
Re: coding style for long conditions (WAS: Re: [PATCH 25/90] ... blinky leds!!)
On 4/6/07, Stefan Richter <[EMAIL PROTECTED]> wrote:
David Brownell wrote:
[...]
>>> 1 if (To control chain reactions, your odds
>>> 2 Improve if you've got cadmium rods) {
>>> 3 In your fission reactor
>>> 4 Their lack is a factor
>>> 5 }
>>> 6 In screams of "A meltdown! Ye gods!"
>>>
>>> Now, the former makes it hard to tell what's condition vs consequent.
>>> (Or whatever the correct technical term is in cases like these.)
>> My fu dictates that continuation lines (line 2 in this example)
>> should have more indent than line 1,
>
> Yes. Where "indent" is measured -- always!! -- in tabs.
> Documentation/Coding style is quite explicit on that point:
>
> Outside of comments, documentation and except in Kconfig,
> spaces are never used for indentation ...
I usually indent this way if expressions exceed the 80 columns limit:
if (foo___ &&
bar___) {
doit;
}
---
I disagree vigorously - the operators should be at the front of the
line, so that the logical structure is clear. [The editor I'm doing
this in won't let me use tabs, so I won't even try to do an
example...]
As other people have noted in this thread, it's a rule that would earn
Emerson's "foolish consistency" label, if it actually were followed
slavishly. In fact, the kernel looks like people tend to do the right
thing, rather than always following the letter of the law.
Tab indenting is a good rule for the general case, but there are also
places (and breaking long conditionals is at the top of the list)
where it's much more important to express the structure, and the
structure has too many logical sub-points to line up with the
relatively small number of 8-space tabs available in an 80-character
line.
Of course, expressions too complicated to fit the rule are also a sign
that you might want to simplify things...
scott
-
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/
Re: coding style for long conditions (WAS: Re: [PATCH 25/90] ... blinky leds!!)
On 4/6/07, Stefan Richter [EMAIL PROTECTED] wrote:
David Brownell wrote:
[...]
1 if (To control chain reactions, your odds
2 Improve if you've got cadmium rods) {
3 In your fission reactor
4 Their lack is a factor
5 }
6 In screams of A meltdown! Ye gods!
Now, the former makes it hard to tell what's condition vs consequent.
(Or whatever the correct technical term is in cases like these.)
My fu dictates that continuation lines (line 2 in this example)
should have more indent than line 1,
Yes. Where indent is measured -- always!! -- in tabs.
Documentation/Coding style is quite explicit on that point:
Outside of comments, documentation and except in Kconfig,
spaces are never used for indentation ...
I usually indent this way if expressions exceed the 80 columns limit:
if (foo___
bar___) {
doit;
}
---
I disagree vigorously - the operators should be at the front of the
line, so that the logical structure is clear. [The editor I'm doing
this in won't let me use tabs, so I won't even try to do an
example...]
As other people have noted in this thread, it's a rule that would earn
Emerson's foolish consistency label, if it actually were followed
slavishly. In fact, the kernel looks like people tend to do the right
thing, rather than always following the letter of the law.
Tab indenting is a good rule for the general case, but there are also
places (and breaking long conditionals is at the top of the list)
where it's much more important to express the structure, and the
structure has too many logical sub-points to line up with the
relatively small number of 8-space tabs available in an 80-character
line.
Of course, expressions too complicated to fit the rule are also a sign
that you might want to simplify things...
scott
-
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/
Re: GPL vs non-GPL device drivers
On 2/17/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote: Per this principle, it would seem that only source code and hand-crafted object code would be governed by copyright, since compilation is also an automated process. --- Well, compilation is probably equivalent to "translation", which is specifically included in the Act as forming a derivative work. scott - 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/
Re: GPL vs non-GPL device drivers
On 2/17/07, Alexandre Oliva [EMAIL PROTECTED] wrote: Per this principle, it would seem that only source code and hand-crafted object code would be governed by copyright, since compilation is also an automated process. --- Well, compilation is probably equivalent to translation, which is specifically included in the Act as forming a derivative work. scott - 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/
Re: GPL vs non-GPL device drivers
On 2/16/07, Dave Neuer <[EMAIL PROTECTED]> wrote: On 2/16/07, David Schwartz <[EMAIL PROTECTED]> wrote: > > (See, among other cases, Lexmark. v. Static > Controls.) A copyright is not a patent, you can only own something if there > are multiple equally good ways to do it and you claim *one* of them. Only in a world where "write a Linux module" is a "functional idea." I don't think that the legal world in the US is an example of such a world, though you clearly do. --- "Interface the xyz device to the Linux kernel" is a functional idea in pretty much the same sense that the Lexmark case involved. You generally can't copyright functional interfaces; there is a strong prejudice towards allowing interoperability. [IANAL and this is, as noted preivously, subject to the winds of judicial favor.] - 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/
Re: GPL vs non-GPL device drivers
On 2/16/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: On Thu, 15 Feb 2007 09:32:30 EST, "linux-os (Dick Johnson)" said: Actually, the *real* reason embedded systems end up using old versions is much simpler. They start developing their code on release 2.X.Y, and they keep their code out-of-tree. Then, when they come up for air, and it's at 2.X.(Y+15), they discover that we weren't kidding when we shipped stable_api_nonsense.txt, and since their code isn't in the tree, they have to do all the API cleanup themselves, because no flock of nit-picking kernel janitor monkeys swarmed over their code and magically fixed it up for them. And unless Y+15 has some *very* compelling reasons to move forward, just sticking at Y suddenly starts looking very good, because watching somebody else's kernel janitor monkeys fix your code is fairly cheap, but paying your own kernel janitor monkeys gets expensive really fast --- No, that misses the core reason why embedded companies ship antigue kernels: because they [we] have a much stiffer concept of "stable" than the Linux community does. We typically freeze components (meaning accepting only critical defect fixes) many months before product ship, because they need several layers of field testing before shipping. We then try to maximize ROI for that frozen version by reusing it (and the things we build on it) in successor products. We do that for years. Yes, it's extremely painful when we decide to upmerge to a later release. So, we wait until the later version is an unavoidable choice, in the meantime downmerging specific patches that we want. scott - 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/
Re: GPL vs non-GPL device drivers
On 2/16/07, Dave Neuer [EMAIL PROTECTED] wrote: On 2/16/07, David Schwartz [EMAIL PROTECTED] wrote: (See, among other cases, Lexmark. v. Static Controls.) A copyright is not a patent, you can only own something if there are multiple equally good ways to do it and you claim *one* of them. Only in a world where write a Linux module is a functional idea. I don't think that the legal world in the US is an example of such a world, though you clearly do. --- Interface the xyz device to the Linux kernel is a functional idea in pretty much the same sense that the Lexmark case involved. You generally can't copyright functional interfaces; there is a strong prejudice towards allowing interoperability. [IANAL and this is, as noted preivously, subject to the winds of judicial favor.] - 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/
Re: GPL vs non-GPL device drivers
On 2/15/07, Gene Heskett <[EMAIL PROTECTED]> wrote: This definition seems to be a bit like nailing jelly to a tree in that so far only one companies legal dept has pursued this to the point of actually getting a court verdict rendered. That was the German ruling a link was given to earlier in this thread(s). --- The German decision did not go anywhere near the question of kernel modules. It was a nice victory that the court decided the license was enforceable, but the details of the license are still largely untested. --- ... I'm a bit like Clint Eastwood here, do you feel lucky? If not, then please comply with the terms of the software you have chosen to base your product on. --- Note that it's not just "lucy", but "rich". Both sides would spend a LOT of money if this went to court in the US. And, of course, "the terms of the software [license]" are exactly what the case would be deciding. There wouldn't be a case unless the two parties had different views of the terms of the license. --- As you have been told here repeatedly, a distribution to your customers of code that is based on the GPL'd kernel headers does bring you into non-compliance with the terms of the GPL. You can do anything you want in house, but the minute that code ships, that is a "distribution" and the GPL applies in full force in that its all made GPL, or you cannot legally ship it. I don't know how it can be said any plainer than that. But of course IANAL, so talk to yours, please. --- I also ANAL, but even so I can point out that your assertion and Greg KH's assertions do not have the force of law. Questions like "what is a derived work" and "what does 'unrelated' mean" in the license are just not black-and-white. I don't like niggling about interpretation, either, especially with material that someone has contributed to the community; I think it's rude and possibly unethical and that not testing the limits avoids any danger of impropriety. But claiming it's clear what the license requires is simply misleading. scott - 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/
Re: GPL vs non-GPL device drivers
On 2/15/07, Geert Uytterhoeven <[EMAIL PROTECTED]> wrote: On Thu, 15 Feb 2007, v j wrote: Personally, I see no real difference between EXPORT_SYMBOL and EXPORT_SYMBOL_GPL. If you derive from GPL'ed code, your code is a derived work. --- I agree with you that there's no difference in law, though I think the difference is that neither creates a derived work. "Derived work" is a very vague notion in law, and the case law on this has varied over time. I think it would be a real crap shoot for both sides to bring this to court, at least in the US. Note, though, that I DO support the OSS equation and believe that companies *should not* use closed-source modules, whether it's legal or not, except in the very specific case of code that also works with other systems. I think this ethical imperative goes with the nature of the author's gift to the community. scott - 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/
Re: GPL vs non-GPL device drivers
On 2/15/07, Miguel Ojeda <[EMAIL PROTECTED]> wrote: Stupid, maybe. But some people just don't want closed-source projects/companies like yours using their free work, without any kind of feedback. Some others don't care, but they could in the future, as it is their code, and that is your risk. --- So, how are such companies any different from the myriad individuals and companies that use Linux on the desktop or in their server rooms without ever modifying it and who also contribute nothing back to the community? They are also, in many (most?) cases taking advantage of the free (as in beer) nature of Linux - saving money by using the work of others without returning anything, but the product builders seem to get a lot more abuse... scott - 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/
Re: GPL vs non-GPL device drivers
On 2/15/07, Theodore Tso <[EMAIL PROTECTED]> wrote: But so what? How will that hurt *Linux*? If the Embedded developers don't contribute changes back, it doesn't hurt us any if they go away and start paying $$$ to VxWorks instead of using Linux for free. --- Well, this is somewhat oversimplified. If the device supports add-on software, that may be good for the FLOSS community even if the underlying OS is partly closed. And if they're returning changes and patches from any work they do in the code kernel (aside from their drivers), that is also good for the community. And there is some value to the community in their hiring and/or growing developers who may later contribute directly to the kernel. And there is even some value in just the publicity and hype for Linux, which helps bring new people in. I'm not saying those things are worth "enough", just that they're worth something. --- Contrawise, if Embedded developers do contribute their device driver changes back to the kernel, they will be fine. ... --- In fairness, though, some of the developers WILL bitch about your not using a recent kernel and not providing patches until products ship, despite that meeting the letter of the license. Some of the notes in this thread do exactly that. And I HAVE seen real developers say something very close to "Your code is based on a kernel too old to have any value to us" even though they would also claim abuse if the code hadn't been made available at all. And I've seen lots of cases where laptop-centric developers rejected or simply ignored code submitted by embedded developers. I'm completely in line with participating fully in the community, but it's important that the mainstream developers recognize that the community is bigger than the laptop/server-room crowd. scott - 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/
Re: GPL vs non-GPL device drivers
On 2/15/07, Stuart MacDonald <[EMAIL PROTECTED]> wrote: Linus does allow for one exception; drivers written for other OSes that happen to compile for Linux as well. I believe this is the POSIX exception mentioned elsethread. However, from your description of requiring GPL-only symbols, I'm pretty sure your driver is a derived work. Since you're distributing it (inside your device), the code must be made available, under the GPL. --- It really is legally unclear. There is substantial case law that supports the idea that interfacing for interoperability does not create a derived work. I agree that it's uncivil to ignore the author's intentions, but I think that it's very unclear whether it's "illegal". The company I work for has made the choice to avoid the question and ship only GPL kernel modules, which seems like the right answer to me. --- You also asserted that the code is only useful to your competitors. That simply is not true. No company suppports a product forever, even if they believe they will. Once that support is gone, the only way to fix bugs or improve the product is to **have the code in hand**. THAT is what the GPL-openness is all about. THAT is when the code is useful to the open source community at large. Since that need is inevitable, the code must be provided up-front, when distribution starts. --- Note that it is possible that what vj said is strictly true. IF the product they ship is non-modifiable, then it's hard to argue that anyone else could maintain it. And if the drivers are for devices proprietary to their hardware, then they have no real value to anyone else. And the drivers MIGHT contain information useful to their actual competitors. I have no knowledge as to whether those conditions actually apply. scott - 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/
Re: GPL vs non-GPL device drivers
On 2/15/07, Stuart MacDonald [EMAIL PROTECTED] wrote: Linus does allow for one exception; drivers written for other OSes that happen to compile for Linux as well. I believe this is the POSIX exception mentioned elsethread. However, from your description of requiring GPL-only symbols, I'm pretty sure your driver is a derived work. Since you're distributing it (inside your device), the code must be made available, under the GPL. --- It really is legally unclear. There is substantial case law that supports the idea that interfacing for interoperability does not create a derived work. I agree that it's uncivil to ignore the author's intentions, but I think that it's very unclear whether it's illegal. The company I work for has made the choice to avoid the question and ship only GPL kernel modules, which seems like the right answer to me. --- You also asserted that the code is only useful to your competitors. That simply is not true. No company suppports a product forever, even if they believe they will. Once that support is gone, the only way to fix bugs or improve the product is to **have the code in hand**. THAT is what the GPL-openness is all about. THAT is when the code is useful to the open source community at large. Since that need is inevitable, the code must be provided up-front, when distribution starts. --- Note that it is possible that what vj said is strictly true. IF the product they ship is non-modifiable, then it's hard to argue that anyone else could maintain it. And if the drivers are for devices proprietary to their hardware, then they have no real value to anyone else. And the drivers MIGHT contain information useful to their actual competitors. I have no knowledge as to whether those conditions actually apply. scott - 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/
Re: GPL vs non-GPL device drivers
On 2/15/07, Theodore Tso [EMAIL PROTECTED] wrote: But so what? How will that hurt *Linux*? If the Embedded developers don't contribute changes back, it doesn't hurt us any if they go away and start paying $$$ to VxWorks instead of using Linux for free. --- Well, this is somewhat oversimplified. If the device supports add-on software, that may be good for the FLOSS community even if the underlying OS is partly closed. And if they're returning changes and patches from any work they do in the code kernel (aside from their drivers), that is also good for the community. And there is some value to the community in their hiring and/or growing developers who may later contribute directly to the kernel. And there is even some value in just the publicity and hype for Linux, which helps bring new people in. I'm not saying those things are worth enough, just that they're worth something. --- Contrawise, if Embedded developers do contribute their device driver changes back to the kernel, they will be fine. ... --- In fairness, though, some of the developers WILL bitch about your not using a recent kernel and not providing patches until products ship, despite that meeting the letter of the license. Some of the notes in this thread do exactly that. And I HAVE seen real developers say something very close to Your code is based on a kernel too old to have any value to us even though they would also claim abuse if the code hadn't been made available at all. And I've seen lots of cases where laptop-centric developers rejected or simply ignored code submitted by embedded developers. I'm completely in line with participating fully in the community, but it's important that the mainstream developers recognize that the community is bigger than the laptop/server-room crowd. scott - 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/
Re: GPL vs non-GPL device drivers
On 2/15/07, Miguel Ojeda [EMAIL PROTECTED] wrote: Stupid, maybe. But some people just don't want closed-source projects/companies like yours using their free work, without any kind of feedback. Some others don't care, but they could in the future, as it is their code, and that is your risk. --- So, how are such companies any different from the myriad individuals and companies that use Linux on the desktop or in their server rooms without ever modifying it and who also contribute nothing back to the community? They are also, in many (most?) cases taking advantage of the free (as in beer) nature of Linux - saving money by using the work of others without returning anything, but the product builders seem to get a lot more abuse... scott - 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/
Re: GPL vs non-GPL device drivers
On 2/15/07, Geert Uytterhoeven [EMAIL PROTECTED] wrote: On Thu, 15 Feb 2007, v j wrote: Personally, I see no real difference between EXPORT_SYMBOL and EXPORT_SYMBOL_GPL. If you derive from GPL'ed code, your code is a derived work. --- I agree with you that there's no difference in law, though I think the difference is that neither creates a derived work. Derived work is a very vague notion in law, and the case law on this has varied over time. I think it would be a real crap shoot for both sides to bring this to court, at least in the US. Note, though, that I DO support the OSS equation and believe that companies *should not* use closed-source modules, whether it's legal or not, except in the very specific case of code that also works with other systems. I think this ethical imperative goes with the nature of the author's gift to the community. scott - 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/
Re: GPL vs non-GPL device drivers
On 2/15/07, Gene Heskett [EMAIL PROTECTED] wrote: This definition seems to be a bit like nailing jelly to a tree in that so far only one companies legal dept has pursued this to the point of actually getting a court verdict rendered. That was the German ruling a link was given to earlier in this thread(s). --- The German decision did not go anywhere near the question of kernel modules. It was a nice victory that the court decided the license was enforceable, but the details of the license are still largely untested. --- ... I'm a bit like Clint Eastwood here, do you feel lucky? If not, then please comply with the terms of the software you have chosen to base your product on. --- Note that it's not just lucy, but rich. Both sides would spend a LOT of money if this went to court in the US. And, of course, the terms of the software [license] are exactly what the case would be deciding. There wouldn't be a case unless the two parties had different views of the terms of the license. --- As you have been told here repeatedly, a distribution to your customers of code that is based on the GPL'd kernel headers does bring you into non-compliance with the terms of the GPL. You can do anything you want in house, but the minute that code ships, that is a distribution and the GPL applies in full force in that its all made GPL, or you cannot legally ship it. I don't know how it can be said any plainer than that. But of course IANAL, so talk to yours, please. --- I also ANAL, but even so I can point out that your assertion and Greg KH's assertions do not have the force of law. Questions like what is a derived work and what does 'unrelated' mean in the license are just not black-and-white. I don't like niggling about interpretation, either, especially with material that someone has contributed to the community; I think it's rude and possibly unethical and that not testing the limits avoids any danger of impropriety. But claiming it's clear what the license requires is simply misleading. scott - 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/
Re: [ANNOUNCE] System Inactivity Monitor v1.0
On 1/25/07, Alessandro Di Marco <[EMAIL PROTECTED]> wrote: "Scott Preece" <[EMAIL PROTECTED]> writes: On 1/25/07, Bodo Eggert <[EMAIL PROTECTED]> wrote: > Imagine one computer serving two users. Two monitors, two keyboards ... --- Good point! Of late I've been working on single-user systems, so it was not at the front of my brain, despite years of building and using multi-user systems. It's a point that multi-user systems have struggled with forever (when somebody inserts a CR in the drive mounted in the system box, which user do you pop up a media player for?). sed s/user X's screensaver/suspend to disk/g < --- Well, a screensaver is associated with a particular user (and screen), but suspend-to-disk is a system-wide activity that would affect all the users. So you need to be able to separate those notions in deciding what actions to take. scott - 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/
Re: [ANNOUNCE] System Inactivity Monitor v1.0
On 1/25/07, Bodo Eggert <[EMAIL PROTECTED]> wrote: Scott Preece <[EMAIL PROTECTED]> wrote: > My own hot button is making sure that the definition of what > constitutes user activity is managed in exactly one place, whether in > the kernel or not. My naive model would be to put the response at user > level, but to provide a single point of definition in the kernel (say, > /dev/useractivity or the equivalent) that the user-level daemon could > listen to. Imagine one computer serving two users. Two monitors, two keyboards ... --- Good point! Of late I've been working on single-user systems, so it was not at the front of my brain, despite years of building and using multi-user systems. It's a point that multi-user systems have struggled with forever (when somebody inserts a CR in the drive mounted in the system box, which user do you pop up a media player for?). I tend to think it's not a kernel-vs-user-space issue, though. To solve it you need, somewhere, a notion of a "user session" and you need some way to separate system-level issues (like low-battery) from user-level issues (like activiating user X's screensaver). - 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/
Re: [ANNOUNCE] System Inactivity Monitor v1.0
On 1/25/07, Bodo Eggert [EMAIL PROTECTED] wrote: Scott Preece [EMAIL PROTECTED] wrote: My own hot button is making sure that the definition of what constitutes user activity is managed in exactly one place, whether in the kernel or not. My naive model would be to put the response at user level, but to provide a single point of definition in the kernel (say, /dev/useractivity or the equivalent) that the user-level daemon could listen to. Imagine one computer serving two users. Two monitors, two keyboards ... --- Good point! Of late I've been working on single-user systems, so it was not at the front of my brain, despite years of building and using multi-user systems. It's a point that multi-user systems have struggled with forever (when somebody inserts a CR in the drive mounted in the system box, which user do you pop up a media player for?). I tend to think it's not a kernel-vs-user-space issue, though. To solve it you need, somewhere, a notion of a user session and you need some way to separate system-level issues (like low-battery) from user-level issues (like activiating user X's screensaver). - 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/
Re: [ANNOUNCE] System Inactivity Monitor v1.0
On 1/25/07, Alessandro Di Marco [EMAIL PROTECTED] wrote: Scott Preece [EMAIL PROTECTED] writes: On 1/25/07, Bodo Eggert [EMAIL PROTECTED] wrote: Imagine one computer serving two users. Two monitors, two keyboards ... --- Good point! Of late I've been working on single-user systems, so it was not at the front of my brain, despite years of building and using multi-user systems. It's a point that multi-user systems have struggled with forever (when somebody inserts a CR in the drive mounted in the system box, which user do you pop up a media player for?). sed s/user X's screensaver/suspend to disk/g EOF I tend to think it's not a kernel-vs-user-space issue, though. To solve it you need, somewhere, a notion of a user session and you need some way to separate system-level issues (like low-battery) from user-level issues (like activiating user X's screensaver). EOF Are you sure? --- Well, a screensaver is associated with a particular user (and screen), but suspend-to-disk is a system-wide activity that would affect all the users. So you need to be able to separate those notions in deciding what actions to take. scott - 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/
Re: [Ksummit-2006-discuss] 2007 Linux Kernel Summit
On 1/24/07, Oleg Verych <[EMAIL PROTECTED]> wrote: > From: "Scott Preece" <[EMAIL PROTECTED]> [] > Hmm - Sounds like it needs to go to Halifax! [I was going to suggest > Reykjavik, but was surprised to see it was in the same time zone as > the UK.] > > I wonder what the geographic center of the kernel community is. > Somebody with boundless energy could harvest the mail headers from > LKML, remove duplicates, and figure out the temporal center from the Do you mean meridian? Interesting idea. Well, i think duplicates will show actual most active timezones, so they mustn't be removed. To somebody with lkml's mbox it's task of new minutes to grep "Data:" header, grab 7th field (UTC shift), and then count (i'm using my boundless teaching energy here ;). --- I only meant to eliminate duplicate addresses, not duplicate timezones. That is, if the goal is to spread the pain of travel evenly over the community members, you don't want to weight those members by how often they send mail to the list! scott - 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/
Re: [Ksummit-2006-discuss] 2007 Linux Kernel Summit
On 1/24/07, Martin Bligh <[EMAIL PROTECTED]> wrote: It's not just the cost of travel by any means - the extra travel time and jetlag involved is huge - having everybody sleep through a conference is distinctly less productive. One of the advantages of the EST timezone locations is that it's at least reasonably central to most of the players involved. Obviously, wherever we hold it, some people get screwed ... the question is what screws the fewest people the least. Personally, I'd prefer PST for purely selfish reasons, but ... ;-) --- Hmm - Sounds like it needs to go to Halifax! [I was going to suggest Reykjavik, but was surprised to see it was in the same time zone as the UK.] I wonder what the geographic center of the kernel community is. Somebody with boundless energy could harvest the mail headers from LKML, remove duplicates, and figure out the temporal center from the timezone information in the headers, but I don't know an easy way to get to air-mile distances... scott - 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/
Re: [Ksummit-2006-discuss] 2007 Linux Kernel Summit
On 1/24/07, Martin Bligh [EMAIL PROTECTED] wrote: It's not just the cost of travel by any means - the extra travel time and jetlag involved is huge - having everybody sleep through a conference is distinctly less productive. One of the advantages of the EST timezone locations is that it's at least reasonably central to most of the players involved. Obviously, wherever we hold it, some people get screwed ... the question is what screws the fewest people the least. Personally, I'd prefer PST for purely selfish reasons, but ... ;-) --- Hmm - Sounds like it needs to go to Halifax! [I was going to suggest Reykjavik, but was surprised to see it was in the same time zone as the UK.] I wonder what the geographic center of the kernel community is. Somebody with boundless energy could harvest the mail headers from LKML, remove duplicates, and figure out the temporal center from the timezone information in the headers, but I don't know an easy way to get to air-mile distances... scott - 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/
Re: [Ksummit-2006-discuss] 2007 Linux Kernel Summit
On 1/24/07, Oleg Verych [EMAIL PROTECTED] wrote: From: Scott Preece [EMAIL PROTECTED] [] Hmm - Sounds like it needs to go to Halifax! [I was going to suggest Reykjavik, but was surprised to see it was in the same time zone as the UK.] I wonder what the geographic center of the kernel community is. Somebody with boundless energy could harvest the mail headers from LKML, remove duplicates, and figure out the temporal center from the Do you mean meridian? Interesting idea. Well, i think duplicates will show actual most active timezones, so they mustn't be removed. To somebody with lkml's mbox it's task of new minutes to grep Data: header, grab 7th field (UTC shift), and then count (i'm using my boundless teaching energy here ;). --- I only meant to eliminate duplicate addresses, not duplicate timezones. That is, if the goal is to spread the pain of travel evenly over the community members, you don't want to weight those members by how often they send mail to the list! scott - 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/
Re: [ANNOUNCE] System Inactivity Monitor v1.0
On 1/23/07, Pavel Machek <[EMAIL PROTECTED]> wrote: Hi1 ... > >But I still believe it can be out. > > Do you believe it could be a user-space daemon or what? Yes, what prevents userspace daemon watching /dev/input/event* to provide this functionality? Pavel --- One possible argument is to allow integrating "input-like" user events with other kinds of system-level events that you might want to have treated like user activity. For instance, our definition of user activity includes: button presses, opening-closing the cover (on a phone), and plugging in or removing memory cards, accessories, or cables. We actually use a mix of kernel and user-space monitoring, today, but would prefer an integrated monitor. A user-space monitor also has more opportunity for races - for instance, deciding that the inactivity timeout has occurred between the time that the user does something and the time that the kernel gets a notification up to user space. My own hot button is making sure that the definition of what constitutes user activity is managed in exactly one place, whether in the kernel or not. My naive model would be to put the response at user level, but to provide a single point of definition in the kernel (say, /dev/useractivity or the equivalent) that the user-level daemon could listen to. scott - 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/
Re: [ANNOUNCE] System Inactivity Monitor v1.0
On 1/23/07, Pavel Machek [EMAIL PROTECTED] wrote: Hi1 ... But I still believe it can be out. Do you believe it could be a user-space daemon or what? Yes, what prevents userspace daemon watching /dev/input/event* to provide this functionality? Pavel --- One possible argument is to allow integrating input-like user events with other kinds of system-level events that you might want to have treated like user activity. For instance, our definition of user activity includes: button presses, opening-closing the cover (on a phone), and plugging in or removing memory cards, accessories, or cables. We actually use a mix of kernel and user-space monitoring, today, but would prefer an integrated monitor. A user-space monitor also has more opportunity for races - for instance, deciding that the inactivity timeout has occurred between the time that the user does something and the time that the kernel gets a notification up to user space. My own hot button is making sure that the definition of what constitutes user activity is managed in exactly one place, whether in the kernel or not. My naive model would be to put the response at user level, but to provide a single point of definition in the kernel (say, /dev/useractivity or the equivalent) that the user-level daemon could listen to. scott - 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/
Re: [ANNOUNCE] System Inactivity Monitor v1.0
On 1/19/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote: On Jan 19 2007 11:45, Scott Preece wrote: > Hi, attached is a patch for your gentable file, rewriting some of the > user prompts to make them more readable. I still don't get why this is called "SIN" in the Kconfig and code texts though the acronym for System Inactivity Monitor would be "SIM". --- The code calls it "System Inactivity Notifier". scott - 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/
Re: [ANNOUNCE] System Inactivity Monitor v1.0
On 1/19/07, Alessandro Di Marco <[EMAIL PROTECTED]> wrote: The patch in attachment fixes some silly bugs of the previous version. Regards, Hi, attached is a patch for your gentable file, rewriting some of the user prompts to make them more readable. Regards, scott --- gentable 2007-01-19 11:39:28.0 -0600 +++ gentable-new 2007-01-19 11:39:28.0 -0600 @@ -31,9 +31,9 @@ cat < reset the global counter to the specified value otherwise => do nothing, the global counter goes on and on and on... @@ -163,8 +163,8 @@ # modprobe sinmod # echo $1 >/proc/sin/table -An "Invalid argument" error signals a mismatch in the table file, usually due -to wrong acpi or input device specified. In these cases restart from scratch -double checking your answers. Have fun! +An "Invalid argument" error indicates a mismatch in the table file, usually +due to specifying an invalid acpi or input device. In that case, restart from +scratch, double checking your inputs. Have fun! EOF
Re: [ANNOUNCE] System Inactivity Monitor v1.0
On 1/19/07, Alessandro Di Marco [EMAIL PROTECTED] wrote:
The patch in attachment fixes some silly bugs of the previous version.
Regards,
Hi, attached is a patch for your gentable file, rewriting some of the
user prompts to make them more readable.
Regards,
scott
--- gentable 2007-01-19 11:39:28.0 -0600
+++ gentable-new 2007-01-19 11:39:28.0 -0600
@@ -31,9 +31,9 @@
cat EOF
-SIN wakes up periodically and checks for user activity occurred in the
-meantime; this options lets you to specify how much frequently SIN should be
-woken-up. Its value is expressed in tenth of seconds.
+SIN wakes up periodically and checks whether user activity has occurred
+since it last ran; the next option lets you to specify how frequently
+SIN should wake up. Its value is expressed in tenth of seconds.
EOF
@@ -45,9 +45,9 @@
cat EOF
-Asleep or not, SIN constantly monitors the input devices searching for user
-activity. This option lets you choose which device have to be monitored. At
-least one device is needed and please avoid the duplicates.
+Asleep or not, SIN constantly monitors the input devices watching for user
+activity. The next option lets you choose which device have to be monitored.
+You must specify at least one device and must not specify duplicates.
EOF
@@ -65,7 +65,7 @@
cat EOF
-SIN produces ACPI events depending on the user activity. To do this you have to
+SIN produces ACPI events depending on the user activity. You must
specify a suitable handler that will be used as originator.
EOF
@@ -74,7 +74,7 @@
cat /proc/sin/acpi
echo
-input Please digit the corresponding number handle
+input Please enter the number corresponding to the handler handle
if [ -z ${handle} ]; then
handle=0
@@ -82,19 +82,19 @@
cat EOF
-SIN produces events in base to rules. Each rule is a triple composed by a
-counter, a type and a data. Once awaken, a global counter is increased if
-SIN detects no user activity and reset to zero, otherwise. When this global
-counter reaches the value specified in the counter field of a rule, an event is
-generated with the corresponding type and data. Clearly, different rules
-should have different type and data fields to convey different signals to
-the user space daemon.
+SIN produces events based on rules. Each rule is a triple composed by a
+counter, a type, and a data value. When SIN awakens, a global counter
+is increased if SIN detects no user activity and reset to zero, otherwise.
+When this global counter reaches the value specified in the counter field
+of a rule, an event is generated with the corresponding type and data.
+Different rules should have different type and data fields to convey
+different signals to the user space daemon.
For example, the rule 60 1 19 produces the ACPI event 0001
-0019 right after one minute of user inactivity (assuming pace=10.)
+0019 when SIN recognizes one minute of user inactivity (assuming pace=10.)
-Please specify each rule as a space-separated triple; to finish just press
-enter.
+Please specify each rule as a space-separated triple on a separate line;
+when finished, just press enter.
EOF
@@ -114,9 +114,9 @@
cat EOF
-A special event has been provided to better help those of us who wanna use SIN
+A special event has been provided to simplify using SIN
as a screen-blanker. It will be generated as soon as some user activity is
-detected, but only after one or more rule have been triggered.
+detected, but only after one or more rules have been triggered.
EOF
@@ -128,16 +128,16 @@
cat EOF
-Usually a rule-list terminates with dead-end actions such as suspend or
-hibernate, requiring the user interaction to wake-up the system. Unfortunately
-this activity occurs when SIN, as well as the kernel, are not ready to capture
-these events yet. As a consequence, no special event will ever be generated and
+Often an SIN event results in suspending or hibernating the system,
+hibernate, requiring user interaction to wake-up the system. Unfortunately
+that interaction occurs when SIN, as well as the kernel, cannot capture
+it. As a consequence, no event will ever be generated and
the system will remain in the state associated with the next-to-last rule
-(e.g. blanked screen, wireless powered off, etc.) In such cases this field
-forces the special event generation, resetting simultaneously the global
-counter to an arbitrary value, so to reinstate the rule-list evaluation to the
-beginning. Possible value ranges are described below, where N is the maximum
-counter in the rule list:
+(e.g. blanked screen, wireless powered off, etc.). The next option
+allows you to request a special event, resetting the global
+counter to an arbitrary value, so to restart the rule-list evaluation.
+Possible value ranges are described below, where N is the maximum
+counter in the current rule list:
[0, N]= reset the global counter to the specified value
otherwise = do
Re: [ANNOUNCE] System Inactivity Monitor v1.0
On 1/19/07, Jan Engelhardt [EMAIL PROTECTED] wrote: On Jan 19 2007 11:45, Scott Preece wrote: Hi, attached is a patch for your gentable file, rewriting some of the user prompts to make them more readable. I still don't get why this is called SIN in the Kconfig and code texts though the acronym for System Inactivity Monitor would be SIM. --- The code calls it System Inactivity Notifier. scott - 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/
Re: Binary Drivers
On 12/26/06, David Schwartz <[EMAIL PROTECTED]> wrote: You buy a phone for $200. The manufacturer only represents that it works with CarrierCo. ... You have the right to do what you like with the phone, of course. It's a great doorstop and a reasonable paper weight. The manufacturer didn't promise the phone's configuration wouldn't become obsolete or that you would be able to change the configuration. Lack of documentation is not an imposition on your rights, and you had no specific promise of documentation from the seller. I have to say, it honestly astonishes me that would people would make arguments like these. Are we so used to these kinds of one-sided arrangements that we've lost our common sense? --- If the manufacturer knew about the forthcoming configuration change, you might have a fraud claim. Otherwise it's just bad luck, which happens sometimes. I'm not familiar with any situations where the manufacturer locks the phone. Locks are usually applied by the carrier in return for a subsidy. Once any contract restrictions are over, you would have the right to attempt to unlock the phone or to find someone who could do so. For most phones in the market today, I understand that to be a relatively easy thing to find. In the US, the Copyright office recently ruled that there should be an exception to the DMCA so that circumventing the lock would not be a DMCA violation. I don't know why you think of this as a particularly unfair situation. There's at least a chance that the phone might be reconfigurable. The phone might as easily have been physically unable to work with the new configuration. If you bought, for instance, an Iridium phone (which worked only on the Iridium satellite network and had no other useful function), it became a paperweight when the network ceased operation. You could sell the device on ebay or attempt to salvage parts of it for other purposes, but otherwise you're just out of luck. scott - 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/
Re: Binary Drivers
On 12/26/06, David Schwartz <[EMAIL PROTECTED]> wrote: It's really common sense. Imagine if you buy the right to use my car, but I don't give you the key. Can I say, "yes, you have the right to use my car, you bought that, but that doesn't mean I have to tell you how to use my car." --- I have to agree with Martin, that the car analogies really bear little relationship with the question of closed-source drivers... My point was that you buy what you buy, under the terms that you agree to. For a house, or a car, the "normal" terms would include any associated accessories, including keys. Keys also have a certain common-law "specialness", because they historically corresponded to the right to access. If you were buying a house or car and the seller was retaining keys (perhaps because they have some historical or personal significance), that would have to be disclosed and it would have to be clear that no rights were associated with the retained keys. --- ... Skipping the rest of the house/car analogies... When you buy a video car, you are *not* buying the right to use that video card with Windows. You are buying all the rights to the video card, to use it any way you please. The manufacturer has no right (because it sold that right when it sold the video card) to interfere or obstruct your right to use it as you please. --- There is a notion of "fitness for purpose" that sometimes applies - if the seller describes the object as fit for a particular purpose, then the seller has an obligation to make sure the object is, in fact, fit for that purpose. However, that's a very limited requirement - it's not required to be fit for any other purpose and being fit for that purpose would not require documentation unless that purpose normally required it. Note that selling a card as suitable for use with Windows would not suggest, in any way, that it was offered as suitable for use with Linux. Again, you buy the right to do anything you like with the object, but the seller has no obligation beyond the agreed terms. --- If you retain some rights over something, then you are not selling it in the normal sense. You are selling a subset of the rights to it, and the buy must be told what rights he is getting and what rights he is not getting. --- Again, while some of the car/house analogies may describe situations where the seller has not conveyed all the rights, the video card situation is completely different. You have the right to do what you like with it and the seller retains no rights. Lack of documentation is not an imposition on your rights, unless you had a specific promise of documentation from the seller. scott - 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/
Re: Binary Drivers
On 12/26/06, David Schwartz [EMAIL PROTECTED] wrote: It's really common sense. Imagine if you buy the right to use my car, but I don't give you the key. Can I say, yes, you have the right to use my car, you bought that, but that doesn't mean I have to tell you how to use my car. --- I have to agree with Martin, that the car analogies really bear little relationship with the question of closed-source drivers... My point was that you buy what you buy, under the terms that you agree to. For a house, or a car, the normal terms would include any associated accessories, including keys. Keys also have a certain common-law specialness, because they historically corresponded to the right to access. If you were buying a house or car and the seller was retaining keys (perhaps because they have some historical or personal significance), that would have to be disclosed and it would have to be clear that no rights were associated with the retained keys. --- ... Skipping the rest of the house/car analogies... When you buy a video car, you are *not* buying the right to use that video card with Windows. You are buying all the rights to the video card, to use it any way you please. The manufacturer has no right (because it sold that right when it sold the video card) to interfere or obstruct your right to use it as you please. --- There is a notion of fitness for purpose that sometimes applies - if the seller describes the object as fit for a particular purpose, then the seller has an obligation to make sure the object is, in fact, fit for that purpose. However, that's a very limited requirement - it's not required to be fit for any other purpose and being fit for that purpose would not require documentation unless that purpose normally required it. Note that selling a card as suitable for use with Windows would not suggest, in any way, that it was offered as suitable for use with Linux. Again, you buy the right to do anything you like with the object, but the seller has no obligation beyond the agreed terms. --- If you retain some rights over something, then you are not selling it in the normal sense. You are selling a subset of the rights to it, and the buy must be told what rights he is getting and what rights he is not getting. --- Again, while some of the car/house analogies may describe situations where the seller has not conveyed all the rights, the video card situation is completely different. You have the right to do what you like with it and the seller retains no rights. Lack of documentation is not an imposition on your rights, unless you had a specific promise of documentation from the seller. scott - 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/
Re: Binary Drivers
On 12/26/06, David Schwartz [EMAIL PROTECTED] wrote: You buy a phone for $200. The manufacturer only represents that it works with CarrierCo. ... You have the right to do what you like with the phone, of course. It's a great doorstop and a reasonable paper weight. The manufacturer didn't promise the phone's configuration wouldn't become obsolete or that you would be able to change the configuration. Lack of documentation is not an imposition on your rights, and you had no specific promise of documentation from the seller. I have to say, it honestly astonishes me that would people would make arguments like these. Are we so used to these kinds of one-sided arrangements that we've lost our common sense? --- If the manufacturer knew about the forthcoming configuration change, you might have a fraud claim. Otherwise it's just bad luck, which happens sometimes. I'm not familiar with any situations where the manufacturer locks the phone. Locks are usually applied by the carrier in return for a subsidy. Once any contract restrictions are over, you would have the right to attempt to unlock the phone or to find someone who could do so. For most phones in the market today, I understand that to be a relatively easy thing to find. In the US, the Copyright office recently ruled that there should be an exception to the DMCA so that circumventing the lock would not be a DMCA violation. I don't know why you think of this as a particularly unfair situation. There's at least a chance that the phone might be reconfigurable. The phone might as easily have been physically unable to work with the new configuration. If you bought, for instance, an Iridium phone (which worked only on the Iridium satellite network and had no other useful function), it became a paperweight when the network ceased operation. You could sell the device on ebay or attempt to salvage parts of it for other purposes, but otherwise you're just out of luck. scott - 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/
Re: Binary Drivers
On 12/25/06, David Schwartz <[EMAIL PROTECTED]> wrote: If I bought the car from the manufacturer, it also must include any rights the manufacturer might have to the car's use. That includes using the car to violate emission control measures. If I didn't buy the right to use the car that way (insofar as that right was owned by the car manufacturer), I didn't buy the whole care -- just *some* of the rights to use it. --- I have no idea why you assume that "having the right to do X" implies "must be told how to do X". The have the right (except as laws prohibit it) to modify the car's systems, but (except for some specific legal requirements) the manufacturer is not required to explain anything, even basic operation. --- If I buy a device that has a safety of some kind, the manufacturer cannot prohibit me from removing or disabling the safety unless some law gives them that authority. ... --- Yes, I agree. However, they are completely allowed to make it arbitrarily hard for you to remove (by, for instance, welding the safety in place). --- > Almost everything around you is controlled by a uP nowadays (it is much > cheaper/preciser to control e.g. the washing machine that way than via the > customary rotating wheels with notches). Did you get the specs for that? > Can you get them? So long as you don't *need* them to use the device, there's no issue. The problem is when you need them to use the device (and not just the ordinary expected way, any reasonable way). Then you are entitled to them. --- Again, (IANAL), I think this is simply a misconception. Buyng a physical object gives you the right to do anything with it that the law allows, but imposes no obligation on the seller to explain it (other than specific restrictions hte law may apply to specific classes of objects for safety or other reasons). It's up to you, in deciding whether to buy it, to decide whether it comes with sufficient documentation to satisfy your needs. scott - 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/
