> "David Schwartz" <[EMAIL PROTECTED]> writes:
> > I don't know who told you that or why, but it's obvious nonsense,
> Correct.
> > Exports should be marked GPL if and only if they cannot be used
> > except in a derivative work. If it is possible to us
David Schwartz [EMAIL PROTECTED] writes:
I don't know who told you that or why, but it's obvious nonsense,
Correct.
Exports should be marked GPL if and only if they cannot be used
except in a derivative work. If it is possible to use them
without taking
sufficient protectable
> The reason I added GPL is not because of some idea that this is all
> "chummy" with the kernel. But because I derived the mcount code from
> glibc's version of mcount. Now you may argue that glibc is under LGPL
> and a non-GPL export is fine. But I've been advised that if I ever take
> code
The reason I added GPL is not because of some idea that this is all
chummy with the kernel. But because I derived the mcount code from
glibc's version of mcount. Now you may argue that glibc is under LGPL
and a non-GPL export is fine. But I've been advised that if I ever take
code from
Marcel Holtmann wrote:
> Lets phrase this in better words as Valdis pointed out: You can't
> distribute an application (binary or source form) under anything else
> than GPL if it uses a GPL library.
This simply cannot be correct. The only way it could be true is if the work
was a derivative
Marcel Holtmann wrote:
Lets phrase this in better words as Valdis pointed out: You can't
distribute an application (binary or source form) under anything else
than GPL if it uses a GPL library.
This simply cannot be correct. The only way it could be true is if the work
was a derivative work
> Don't ignore, "mere aggregation of another work not based on the Program
> with the Program (or with a work based on the Program) on a volume of a
> storage or distribution medium does not bring the other work under the
> scope of this License." Static linking certainly makes something part
>
Don't ignore, mere aggregation of another work not based on the Program
with the Program (or with a work based on the Program) on a volume of a
storage or distribution medium does not bring the other work under the
scope of this License. Static linking certainly makes something part
of the
> IANAL, but when looking at the "But when you distribute the same
> sections as part of a whole which is a work based on the Program, the
> distribution of the whole must be on the terms of this License" of the
> GPLv2 I would still consult a lawyer before e.g. selling a laptop with a
>
Adrian Bunk wrote:
> The Linux kernel is licenced under the GPLv2.
>
> Ndiswrapper loads and executes code with not GPLv2 compatible licences
> in a way in the kernel that might be considered similar to a GPLv2'ed
> userspace program dlopen() a dynamic library file with a not GPLv2
>
Adrian Bunk wrote:
The Linux kernel is licenced under the GPLv2.
Ndiswrapper loads and executes code with not GPLv2 compatible licences
in a way in the kernel that might be considered similar to a GPLv2'ed
userspace program dlopen() a dynamic library file with a not GPLv2
compatible
IANAL, but when looking at the But when you distribute the same
sections as part of a whole which is a work based on the Program, the
distribution of the whole must be on the terms of this License of the
GPLv2 I would still consult a lawyer before e.g. selling a laptop with a
Combined reponses to many fragmented comments in this thread. No two
consecutive excerpts are from the same person.
> Interesting... I never heard about this `transferring ownership of a
> single copy not involving GPL'.
>
> Note that some lawyers claim that at trade shows, you should not hand
> I wouldn't quite say that. I wasn't going to comment, but...personally,
> I actually disagree with the assertions that ndiswrapper isn't causing
> proprietary code to link against GPL functions in the kernel (how is
> an NDIS implementation any different than a shim layer provided to
> load a
I wouldn't quite say that. I wasn't going to comment, but...personally,
I actually disagree with the assertions that ndiswrapper isn't causing
proprietary code to link against GPL functions in the kernel (how is
an NDIS implementation any different than a shim layer provided to
load a
Combined reponses to many fragmented comments in this thread. No two
consecutive excerpts are from the same person.
Interesting... I never heard about this `transferring ownership of a
single copy not involving GPL'.
Note that some lawyers claim that at trade shows, you should not hand
> On Thu, 17 Jan 2008, David Schwartz wrote:
> > Nonsense. The 'kfree' function *destroys* the object pointer to by the
> > pointer. How can you describe that as not doing anything to the object?
>
> Here's an idea. Think it through.
>
> Why don't we need write perm
On Thu, 17 Jan 2008, David Schwartz wrote:
Nonsense. The 'kfree' function *destroys* the object pointer to by the
pointer. How can you describe that as not doing anything to the object?
Here's an idea. Think it through.
Why don't we need write permissions to a file to unlink it?
You
> On Thu, 17 Jan 2008, David Schwartz wrote:
> > > "const" has nothing to do with "logical state". It has one
> > > meaning, and
> > > one meaning only: the compiler should complain if that
> > > particular type is
> > >
> On Thu, 17 Jan 2008, David Schwartz wrote:
> > No, that's not what it means. It has nothing to do with memory.
> > It has to do
> > with logical state.
> Blah. That's just your own made-up explanation of what you think "const"
> should mean. It has no log
> On Thu, 17 Jan 2008, David Schwartz wrote:
> > Which does change the thing the pointer points to. It goes from being a
> > valid object to not existing.
> No. It's the *pointer* that is no longer valid.
The pointer is no longer valid because the object it pointed t
On Thu, 17 Jan 2008, David Schwartz wrote:
Which does change the thing the pointer points to. It goes from being a
valid object to not existing.
No. It's the *pointer* that is no longer valid.
The pointer is no longer valid because the object it pointed to no longer
exists. The pointer
On Thu, 17 Jan 2008, David Schwartz wrote:
No, that's not what it means. It has nothing to do with memory.
It has to do
with logical state.
Blah. That's just your own made-up explanation of what you think const
should mean. It has no logical background or any basis in the C language
On Thu, 17 Jan 2008, David Schwartz wrote:
const has nothing to do with logical state. It has one
meaning, and
one meaning only: the compiler should complain if that
particular type is
used to do a write access.
Right, exactly.
So why do you complain?
kfree() literally
Jan Engelhardt wrote:
> On Dec 21 2007 17:56, Herbert Xu wrote:
> >>
> >> I do not believe "opinions" are relevant here. Relevant would be cites
> >> from respected style guides (Fowlers, Oxford Guide To Style et al.) to
> >> show they do not need a full stop.
> >>
> >> I've not found one, but I
Jan Engelhardt wrote:
On Dec 21 2007 17:56, Herbert Xu wrote:
I do not believe opinions are relevant here. Relevant would be cites
from respected style guides (Fowlers, Oxford Guide To Style et al.) to
show they do not need a full stop.
I've not found one, but I am open to
> Has anyone *proven* that using uninitialized data this way is safe?
You can probably find dozens of things in the Linux kernel that have not
been proven to be safe. That means nothing.
> As
> a *user* of this stuff, I'm *very* hesitant to trust Linux's RNG when I
> hear things like this.
> The bottom line: At a cost of at most three unpredictable branches
> (whether to clear the bytes in the last word with indices congruent
> to 1, 2, or 3 modulo 4), then the code can reduce the risk from something
> small but positive, to zero. This is very inexpensive insurance.
> John
The bottom line: At a cost of at most three unpredictable branches
(whether to clear the bytes in the last word with indices congruent
to 1, 2, or 3 modulo 4), then the code can reduce the risk from something
small but positive, to zero. This is very inexpensive insurance.
John Reiser,
Has anyone *proven* that using uninitialized data this way is safe?
You can probably find dozens of things in the Linux kernel that have not
been proven to be safe. That means nothing.
As
a *user* of this stuff, I'm *very* hesitant to trust Linux's RNG when I
hear things like this. (Hint:
Kyle Moffett wrote:
> That is a *terrible* disgusting way to use yield. Better options:
>(1) inotify/dnotify
Sure, tie yourself to a Linux-specific mechanism that may or may not work
over things like NFS. That's much worse.
>(2) create a "foo.lock" file and put the mutex in that
Kyle Moffett wrote:
That is a *terrible* disgusting way to use yield. Better options:
(1) inotify/dnotify
Sure, tie yourself to a Linux-specific mechanism that may or may not work
over things like NFS. That's much worse.
(2) create a foo.lock file and put the mutex in that
Right,
Phillip Susi wrote:
> What good does using multiple levels of RNG do? Why seed one RNG from
> another? Wouldn't it be better to have just one RNG that everybody
> uses? Doesn't the act of reading from the RNG add entropy to it, since
> no one reader has any idea how often and at what times
Phillip Susi wrote:
What good does using multiple levels of RNG do? Why seed one RNG from
another? Wouldn't it be better to have just one RNG that everybody
uses? Doesn't the act of reading from the RNG add entropy to it, since
no one reader has any idea how often and at what times other
> heh, along those lines you could also do
>
> dmesg > /dev/random
>
>
>
> dmesg often has machine-unique identifiers of all sorts (including the
> MAC address, if you have an ethernet driver loaded)
>
> Jeff
A good three-part solution would be:
1) Encourage distributions to do
heh, along those lines you could also do
dmesg /dev/random
grin
dmesg often has machine-unique identifiers of all sorts (including the
MAC address, if you have an ethernet driver loaded)
Jeff
A good three-part solution would be:
1) Encourage distributions to do dmesg
> > A scope probe will allow you to see if there is
> > a clock signal. That's all. You can't determine
> > its quality. A 4-inch ground lead on the scope
> > probe will result in 10-20% overshoot and undershoot
> > being observed.
> I don't understand this 10-20% figure.
> (0V + 10-20% is still
A scope probe will allow you to see if there is
a clock signal. That's all. You can't determine
its quality. A 4-inch ground lead on the scope
probe will result in 10-20% overshoot and undershoot
being observed.
I don't understand this 10-20% figure.
(0V + 10-20% is still 0V.)
If
> * Mark Lord <[EMAIL PROTECTED]> wrote:
> > Ack. And what of the suggestion to try to ensure that a yielding task
> > simply not end up as the very next one chosen to run? Maybe by
> > swapping it with another (adjacent?) task in the tree if it comes out
> > on top again?
> we did that too
Chris Friesen wrote:
> David Schwartz wrote:
> > I've asked versions of this question at least three times
> > and never gotten
> > anything approaching a straight answer:
> >
> > 1) What is the current default 'sched_yield' behavior?
> >
&
I've asked versions of this question at least three times and never
gotten
anything approaching a straight answer:
1) What is the current default 'sched_yield' behavior?
2) What is the current alternate 'sched_yield' behavior?
3) Are either of them sensible?
I've asked versions of this question at least three times and never
gotten
anything approaching a straight answer:
1) What is the current default 'sched_yield' behavior?
2) What is the current alternate 'sched_yield' behavior?
3) Are either of them sensible?
Chris Friesen wrote:
David Schwartz wrote:
I've asked versions of this question at least three times
and never gotten
anything approaching a straight answer:
1) What is the current default 'sched_yield' behavior?
2) What is the current alternate 'sched_yield' behavior
* Mark Lord [EMAIL PROTECTED] wrote:
Ack. And what of the suggestion to try to ensure that a yielding task
simply not end up as the very next one chosen to run? Maybe by
swapping it with another (adjacent?) task in the tree if it comes out
on top again?
we did that too for quite
> > Then init_net needs to be not GPL limited. Sorry, we need to allow
> > non GPL network drivers. There is a fine line between keeping the
> Why - they aren't exactly likely to be permissible by law
Really? What law and/or what clause in the GPL says that derivative works
have to be licensed
Then init_net needs to be not GPL limited. Sorry, we need to allow
non GPL network drivers. There is a fine line between keeping the
Why - they aren't exactly likely to be permissible by law
Really? What law and/or what clause in the GPL says that derivative works
have to be licensed
> Thanks for the help. Someday, I hope to understand this stuff.
>
> Larry
Any code either deals with an object or it doesn't. If it doesn't deal with
that object, it should not be acquiring locks on that object. If it does
deal with that object, it must know the internal details of that object,
Thanks for the help. Someday, I hope to understand this stuff.
Larry
Any code either deals with an object or it doesn't. If it doesn't deal with
that object, it should not be acquiring locks on that object. If it does
deal with that object, it must know the internal details of that object,
> David Schwartz <[EMAIL PROTECTED]> wrote:
> >> Regardless of whatever verifications your application is doing
> >> on the data, it is not checksumming the ports and that's what
> >> the pseudo-header is helping with.
> > So what? We are in the case wh
David Schwartz [EMAIL PROTECTED] wrote:
Regardless of whatever verifications your application is doing
on the data, it is not checksumming the ports and that's what
the pseudo-header is helping with.
So what? We are in the case where the data has already gotten
to him. If it
got
> Regardless of whatever verifications your application is doing
> on the data, it is not checksumming the ports and that's what
> the pseudo-header is helping with.
So what? We are in the case where the data has already gotten to him. If it
got to him in error, he'll reject it anyway. The
Regardless of whatever verifications your application is doing
on the data, it is not checksumming the ports and that's what
the pseudo-header is helping with.
So what? We are in the case where the data has already gotten to him. If it
got to him in error, he'll reject it anyway. The receive
> > I use libuuid and I assume libuuid uses some uuid generator support
> > from the kernel.
>
> No, it does not. It's pure userspace and may produce double UUIDs.
>
> > libuuid comes from a package that Ted's maintain IIRC.
> >
> > I (my company) use uuid to uniquely identify objects in a
I use libuuid and I assume libuuid uses some uuid generator support
from the kernel.
No, it does not. It's pure userspace and may produce double UUIDs.
libuuid comes from a package that Ted's maintain IIRC.
I (my company) use uuid to uniquely identify objects in a distributed
> What I suppose is that people porting BSD code to Linux don't mean
> closing the doors for back-porting changes. They are simply unaware
> or forget about the possibility of dual licensing. Obviously, each
> submitter should read Documentation/SubmittingDrivers, where it is
> explicitly stated.
What I suppose is that people porting BSD code to Linux don't mean
closing the doors for back-porting changes. They are simply unaware
or forget about the possibility of dual licensing. Obviously, each
submitter should read Documentation/SubmittingDrivers, where it is
explicitly stated. Yet
> Another conclusion from the cited text is that in contrast with what
> was stated before on the gcc mailing list, it is not required to
> declare thread-shared variables volatile if that thread-shared data is
> consistently protected by calls to locking functions.
>
> Bart Van Assche.
It all
Another conclusion from the cited text is that in contrast with what
was stated before on the gcc mailing list, it is not required to
declare thread-shared variables volatile if that thread-shared data is
consistently protected by calls to locking functions.
Bart Van Assche.
It all depends
Eric Dumazet wrote:
> Events are not necessarly reported "by descriptors". epoll uses an opaque
> field provided by the user.
>
> It's up to the user to properly chose a tag that will makes sense
> if the user
> app is playing dup()/close() games for example.
Great. So the only issue then is
Eric Dumazet wrote:
Events are not necessarly reported by descriptors. epoll uses an opaque
field provided by the user.
It's up to the user to properly chose a tag that will makes sense
if the user
app is playing dup()/close() games for example.
Great. So the only issue then is that the
> 6) Epoll removes the file from the set, when the *kernel* object gets
>closed (internal use-count goes to zero)
>
> With that in mind, how can the code snippet above trigger a removal from
> the epoll set?
I don't see how that can be. Suppose I add fd 8 to an epoll set.
Suppose fd
6) Epoll removes the file from the set, when the *kernel* object gets
closed (internal use-count goes to zero)
With that in mind, how can the code snippet above trigger a removal from
the epoll set?
I don't see how that can be. Suppose I add fd 8 to an epoll set.
Suppose fd
5 is
> Well, yeah. I know what you mean. However, at this moment, some gcc
> developers are trying really hard not to be total d*ckheads about this
> issue, but get gcc fixed. Give us a chance.
>
> Andrew.
Can we get some kind of consensus that 'optimizations' that add writes to
any object that
Well, yeah. I know what you mean. However, at this moment, some gcc
developers are trying really hard not to be total d*ckheads about this
issue, but get gcc fixed. Give us a chance.
Andrew.
Can we get some kind of consensus that 'optimizations' that add writes to
any object that the
I asked a collection of knowledgeable people I know about the issue. The
consensus is that the optimization is not permitted in POSIX code but that
it is permitted in pure C code. The basic argument goes like this:
To make POSIX-compliant code even possible, surely optimizations
I asked a collection of knowledgeable people I know about the issue. The
consensus is that the optimization is not permitted in POSIX code but that
it is permitted in pure C code. The basic argument goes like this:
To make POSIX-compliant code even possible, surely optimizations
> Well that's exactly right. For threaded programs (and maybe even
> real-world non-threaded ones in general), you don't want to be
> even _reading_ global variables if you don't need to. Cache misses
> and cacheline bouncing could easily cause performance to completely
> tank in some cases while
Well that's exactly right. For threaded programs (and maybe even
real-world non-threaded ones in general), you don't want to be
even _reading_ global variables if you don't need to. Cache misses
and cacheline bouncing could easily cause performance to completely
tank in some cases while only
> From: Intel(R) 64 and IA-32 Architectures Software Developer's Manual
> Volume 3A:
>
>"7.2.2 Memory Ordering in P6 and More Recent Processor Families
> ...
> 1. Reads can be carried out speculatively and in any order.
> ..."
>
> So, it looks to me like almost the 1-st
From: Intel(R) 64 and IA-32 Architectures Software Developer's Manual
Volume 3A:
7.2.2 Memory Ordering in P6 and More Recent Processor Families
...
1. Reads can be carried out speculatively and in any order.
...
So, it looks to me like almost the 1-st Commandment. Some
Adrian Bunk wrote:
> even for dynamically linking including non-GPL code is not white but
> already dark grey.
IANAL, but personally, I think it's perfectly black and white.
No mechanical combination (that means compressing, linking, tarring, compiling,
or whatever) can create a work for
Adrian Bunk wrote:
even for dynamically linking including non-GPL code is not white but
already dark grey.
IANAL, but personally, I think it's perfectly black and white.
No mechanical combination (that means compressing, linking, tarring, compiling,
or whatever) can create a work for
> On 10/04/2007 07:39 PM, David Schwartz wrote:
> > But this is just a preposterous position to put him in. If there's no
> > reproduceable test case, then why should he care that one
> > program he can't
> > even see works badly? If you care, you fix it.
> Peo
David Miller wrote:
> Using an unpublishable benchmark, whose results even cannot be
> published, really stretches the limits of "reasonable" don't you
> think?
>
> This "SLUB isn't ready yet" bullshit is just a shamans dance which
> distracts attention away from the real problem, which is that
David Miller wrote:
Using an unpublishable benchmark, whose results even cannot be
published, really stretches the limits of reasonable don't you
think?
This SLUB isn't ready yet bullshit is just a shamans dance which
distracts attention away from the real problem, which is that a
On 10/04/2007 07:39 PM, David Schwartz wrote:
But this is just a preposterous position to put him in. If there's no
reproduceable test case, then why should he care that one
program he can't
even see works badly? If you care, you fix it.
People have been trying for years to make
> From the userlevel, can I get an estimate of "amount of entropy"
> in /dev/random, that is, the estimate of number of bytes
> readable until it blocks ? Of course multiple processes
> can read bytes and this would not be exact ... but still .. as an upper
> boundary estimate ?
>
> Thanks
>
This is a combined response to Arjan's:
> that's also what trylock is for... as well as spinaphores...
> (you can argue that futexes should be more intelligent and do
> spinaphore stuff etc... and I can buy that, lets improve them in the
> kernel by any means. But userspace yield() isn't the
This is a combined response to Arjan's:
that's also what trylock is for... as well as spinaphores...
(you can argue that futexes should be more intelligent and do
spinaphore stuff etc... and I can buy that, lets improve them in the
kernel by any means. But userspace yield() isn't the answer.
From the userlevel, can I get an estimate of amount of entropy
in /dev/random, that is, the estimate of number of bytes
readable until it blocks ? Of course multiple processes
can read bytes and this would not be exact ... but still .. as an upper
boundary estimate ?
Thanks
Yakov
Yes.
> yielding IS blocking. Just with indeterminate fuzzyness added to it
Yielding is sort of blocking, but the difference is that yielding will not
idle the CPU while blocking might. Yielding is sometimes preferable to
blocking in a case where the thread knows it can make forward progress even
Arjan van de Ven wrote:
> > It can occasionally be an optimization. You may have a case where you
> > can do something very efficiently if a lock is not held, but you
> > cannot afford to wait for the lock to be released. So you check the
> > lock, if it's held, you yield and then check again.
> These are generic statements, but i'm _really_ interested in the
> specifics. Real, specific code that i can look at. The typical Linux
> distro consists of in execess of 500 millions of lines of code, in tens
> of thousands of apps, so there really must be some good, valid and
> "right" use of
> * Jarek Poplawski <[EMAIL PROTECTED]> wrote:
>
> > BTW, it looks like risky to criticise sched_yield too much: some
> > people can misinterpret such discussions and stop using this at all,
> > even where it's right.
> Really, i have never seen a _single_ mainstream app where the use of
>
* Jarek Poplawski [EMAIL PROTECTED] wrote:
BTW, it looks like risky to criticise sched_yield too much: some
people can misinterpret such discussions and stop using this at all,
even where it's right.
Really, i have never seen a _single_ mainstream app where the use of
sched_yield() was
These are generic statements, but i'm _really_ interested in the
specifics. Real, specific code that i can look at. The typical Linux
distro consists of in execess of 500 millions of lines of code, in tens
of thousands of apps, so there really must be some good, valid and
right use of
Arjan van de Ven wrote:
It can occasionally be an optimization. You may have a case where you
can do something very efficiently if a lock is not held, but you
cannot afford to wait for the lock to be released. So you check the
lock, if it's held, you yield and then check again. If that
yielding IS blocking. Just with indeterminate fuzzyness added to it
Yielding is sort of blocking, but the difference is that yielding will not
idle the CPU while blocking might. Yielding is sometimes preferable to
blocking in a case where the thread knows it can make forward progress even
> > I think the real fix would be for iperf to use blocking network IO
> > though, or maybe to use a POSIX mutex or POSIX semaphores.
>
> So it's definitely not a bug in the kernel, only in iperf?
Martin:
Actually, in this case I think iperf is doing the right thing (though not
the best thing)
I think the real fix would be for iperf to use blocking network IO
though, or maybe to use a POSIX mutex or POSIX semaphores.
So it's definitely not a bug in the kernel, only in iperf?
Martin:
Actually, in this case I think iperf is doing the right thing (though not
the best thing) and
Ack, sorry, I'm wrong.
Please ignore me, if you weren't already.
I'm glad to hear this will be fixed. The task should be moved last for its
priority level.
DS
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
Chris Friesen wrote:
> > The yielding task has given up the cpu. The other task should get to
> > run for a timeslice (or whatever the equivalent is in CFS) until the
> > yielding task again "becomes head of the thread list".
> Are you sure this isn't happening? I'll run some tests on my SMP
>
> David Schwartz wrote:
> > Nonsense. The task is always ready-to-run. There is no reason
> > its CPU should
> > be low. This bug report is based on a misunderstanding of what yielding
> > means.
> The yielding task has given up the cpu. The other task shoul
> The CFS scheduler does not seem to implement sched_yield correctly. If one
> program loops with a sched_yield and another program prints out timing
> information in a loop. You will see that if both are taskset to
> the same core
> that the timing stats will be twice as long as when they are on
The CFS scheduler does not seem to implement sched_yield correctly. If one
program loops with a sched_yield and another program prints out timing
information in a loop. You will see that if both are taskset to
the same core
that the timing stats will be twice as long as when they are on
David Schwartz wrote:
Nonsense. The task is always ready-to-run. There is no reason
its CPU should
be low. This bug report is based on a misunderstanding of what yielding
means.
The yielding task has given up the cpu. The other task should get to
run for a timeslice (or whatever
Chris Friesen wrote:
The yielding task has given up the cpu. The other task should get to
run for a timeslice (or whatever the equivalent is in CFS) until the
yielding task again becomes head of the thread list.
Are you sure this isn't happening? I'll run some tests on my SMP
system
Ack, sorry, I'm wrong.
Please ignore me, if you weren't already.
I'm glad to hear this will be fixed. The task should be moved last for its
priority level.
DS
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo
> "David Schwartz" <[EMAIL PROTECTED]> writes:
> > My point is that you *cannot* prevent a recipient of a
> > derivative work from
> > receiving any rights under either the GPL or the BSD to any protectable
> > elements in that work.
>
> Of cou
Kryzstof Halasa writes:
> "David Schwartz" <[EMAIL PROTECTED]> writes:
>
> > Theodore Tso writes:
>
> hardly
A apologize for the error in attribution.
> > Of course you don't need a license to *use* the derived work.
> > You never need
> >
1 - 100 of 676 matches
Mail list logo
