On 4/23/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
Basically this hack is bad on policy grounds because it is giving X an
"legislated, unfair monopoly" on the system. It's the equivalent of a
state-guaranteed monopoly in certain 'strategic industries'. It has some
advantages but it is very much n
On 4/19/07, hui Bill Huey <[EMAIL PROTECTED]> wrote:
DSP operations like, particularly with digital synthesis, tend to max
the CPU doing vector operations on as many processors as it can get
a hold of. In a live performance critical application, it's important
to be able to deliver a protected am
On 4/19/07, Lee Revell <[EMAIL PROTECTED]> wrote:
IMHO audio streamers should use SCHED_FIFO thread for time critical
work. I think it's insane to expect the scheduler to figure out that
these processes need low latency when they can just be explicit about
it. "Professional" audio software does
On 4/19/07, Alan Cox <[EMAIL PROTECTED]> wrote:
The troll is back I see.
Troll, shmoll. I call 'em like I see 'em. As much as I like and
depend on Linux, and as much as I respect the contributions and the
ideals of the EXPORT_SYMBOL_GPL partisans, they're spreading needless
FUD by spraying "p
On 4/19/07, Con Kolivas <[EMAIL PROTECTED]> wrote:
The cpu scheduler core is a cpu bandwidth and latency
proportionator and should be nothing more or less.
Not really. The CPU scheduler is (or ought to be) what electric
utilities call an economic dispatch mechanism -- a real-time
controller wh
On 4/19/07, Chris Bergeron <[EMAIL PROTECTED]> wrote:
It just seemed like it might be interesting and I couldn't find anything
to shed light on the error itself in the mailing list logs, and I'm
curious at what's happening.
What's happening is that some kernel developers don't like Linus's
stan
On 4/19/07, Gene Heskett <[EMAIL PROTECTED]> wrote:
Having tried re-nicing X a while back, and having the rest of the system
suffer in quite obvious ways for even 1 + or - from its default felt pretty
bad from this users perspective.
It is my considered opinion (yeah I know, I'm just a leaf in t
On 4/18/07, Matt Mackall <[EMAIL PROTECTED]> wrote:
For the record, you actually don't need to track a whole NxN matrix
(or do the implied O(n**3) matrix inversion!) to get to the same
result. You can converge on the same node weightings (ie dynamic
priorities) by applying a damped function at ea
On 4/17/07, William Lee Irwin III <[EMAIL PROTECTED]> wrote:
The ongoing scheduler work is on a much more basic level than these
affairs I'm guessing you googled. When the basics work as intended it
will be possible to move on to more advanced issues.
OK, let me try this in smaller words for pe
On 4/17/07, Peter Williams <[EMAIL PROTECTED]> wrote:
The other way in which the code deviates from the original as that (for
a few years now) I no longer calculated CPU bandwidth usage directly.
I've found that the overhead is less if I keep a running average of the
size of a tasks CPU bursts an
On 4/16/07, Peter Williams <[EMAIL PROTECTED]> wrote:
Note that I talk of run queues
not CPUs as I think a shift to multiple CPUs per run queue may be a good
idea.
This observation of Peter's is the best thing to come out of this
whole foofaraw. Looking at what's happening in CPU-land, I think
do_acct_process (in kernel/acct.c) bypasses vfs_write and calls
file->f_op->write directly. It therefore bypasses various sanity
checks, some of which appear applicable (notably inode->i_flock &&
MANDATORY_LOCK(inode)) and others of which do not (oversize request,
access_ok, etc.). It also negle
Thanks Alan, this is really helpful -- I'll see if I can figure out
kprobes. It is not immediately obvious to me how to use them to trace
function calls in userspace, but I'll read up.
On 3/13/07, Alan Cox <[EMAIL PROTECTED]> wrote:
> But on that note -- do you have any idea how one might get l
It appears that there are (at least) two ways to get the inode (if
any) associated with an open file: f_mapping->host (pagecache?) and
f_path.dentry->d_inode (dentry cache?). generic_file_llseek uses
f_mapping->host; everything else in read_write.c uses
f_path.dentry->d_inode. do_sendfile checks
In case anyone cares, this is a snippet of my work-in-progress
read_write.c illustrating how I might handle f_pos. Can anyone point
me to data showing whether it's worth avoiding the spinlock when the
"struct file" is not shared between threads? (In my world,
correctness comes before code-bummin
On 3/13/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
Michael, please stop spreading this utter bullshit _now_. You're so
full of half-knowledge that it's not funny anymore, and you try
to insult people knowing a few magniutes more than you left and right.
Thank you Christoph for that infor
Clearly f_pos atomicity has been handled differently in the not-so-distant past:
http://www.mail-archive.com/linux-fsdevel@vger.kernel.org/msg01628.html
And equally clearly the current generic_file_llseek semantics are
erroneous for large offsets, and we shouldn't be taking the inode
mutex in an
On 3/13/07, David Miller <[EMAIL PROTECTED]> wrote:
You're not even safe over standard output, simply run the program over
ssh and you suddenly have socket semantics to deal with.
I'm intimately familiar with this one. Easily worked around by piping
the output through cat or tee. Not that one
On 3/12/07, Alan Cox <[EMAIL PROTECTED]> wrote:
> Writing to a file from multiple processes is not usually the problem.
> Writing to a common "struct file" from multiple threads is.
Not normally because POSIX sensibly invented pread/pwrite. Forgot
preadv/pwritev but they did the basics and end o
On 3/12/07, Bodo Eggert <[EMAIL PROTECTED]> wrote:
On Mon, 12 Mar 2007, Michael K. Edwards wrote:
> That's fine when you're doing integration test, and should probably be
> the default during development. But if the race is first exposed in
> the field, or if t
On 3/12/07, Bodo Eggert <[EMAIL PROTECTED]> wrote:
Michael K. Edwards <[EMAIL PROTECTED]> wrote:
> Actually, I think it would make the kernel (negligibly) faster to bump
> f_pos before the vfs_write() call.
This is a security risk.
other process:
unlink(secre
I apologize for throwing around words like "stupid". Whether or not
the current semantics can be improved, that's not a constructive way
to characterize them. I'm sorry.
As three people have ably pointed out :-), the particular case of a
pipe/FIFO isn't seekable and doesn't need the f_pos membe
On 3/8/07, Benjamin LaHaise <[EMAIL PROTECTED]> wrote:
Any number of things can cause a short write to occur, and rewinding the
file position after the fact is just as bad. A sane app has to either
serialise the writes itself or use a thread safe API like pwrite().
Not on a pipe/FIFO. Short w
On 3/8/07, Eric Dumazet <[EMAIL PROTECTED]> wrote:
Dont even try, you *cannot* do that, without breaking the standards, or
without a performance drop.
The only safe way would be to lock the file during the whole read()/write()
syscall, and we dont want this (this would be more expensive than cur
On 3/8/07, Eric Dumazet <[EMAIL PROTECTED]> wrote:
Absolutely not. We dont want to slow down kernel 'just in case a fool might
want to do crazy things'
Actually, I think it would make the kernel (negligibly) faster to bump
f_pos before the vfs_write() call. Unless fget_light sets fput_needed
o
On 3/8/07, Eric Dumazet <[EMAIL PROTECTED]> wrote:
Nothing in the manuals says that write() on same fd should be non racy : In
particular file pos might be undefined. There is a reason pwrite() exists.
Kernel doesnt have to enforce thread safety as standard is quite clear.
I know the standard
from sys_write():
file = fget_light(fd, &fput_needed);
if (file) {
loff_t pos = file_pos_read(file);
ret = vfs_write(file, buf, count, &pos);
file_pos_write(file, pos);
fput_light(file, fput_needed);
}
Surely that's
On 3/8/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
So anybody who would "go with the Berkeley crowd" really shows a lot of
bad taste, I'm afraid. The Berkeley crowd really messed up here, and it's
so long ago that I don't think there is any point in us trying to fix it
any more.
Well, they di
On 3/8/07, Davide Libenzi wrote:
The reason for the special function, was not to provide a non-blocking
behaviour with zero timeout (that just a side effect), but to read the
siginfo. I was all about using read(2) (and v1 used it), but when you have
to transfer complex structures over it, it bec
On 3/7/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
No, I just checked, and Intel's own optimization manual makes it clear
that you should be careful. They talk about performance penalties due to
resource constraints - which makes tons of sense with a core that is good
at handling its own resour
I wrote:
I didn't see any clean way to intersperse overwrites and appends to a
record-structured file without using vfs_llseek, which steps on f_pos.
The context, of course, is an attempt to fix -ENOPATCH with regard to
the netlink-based AIO submission scheme I outlined a couple of days
ago. :
On 3/7/07, Alan Cox <[EMAIL PROTECTED]> wrote:
The right way IMHO would be to do the work that was done for pread/pwrite
and implement preadv/pwritev. The moment you want to do atomic things
with the file->f_pos instead of doing it with a local passed pos value it
gets ugly.. why do you need to d
On 3/7/07, Linus Torvalds <[EMAIL PROTECTED]> wrote
Yeah, I'm not at all surprised. Any implementation of "prefetch" that
doesn't just turn into a no-op if the TLB entry doesn't exist (which makes
them weaker for *actual* prefetching) will generally have a hard time with
a NULL pointer. Exactly b
Suppose I want to create an atomic llseek+writev operation. Is this
more or less sufficient:
ssize_t ret = -EBADF;
file = fget_light(fd, &fput_needed);
if (file) {
if (unlikely(origin > 2)) {
ret = -EINVAL;
} else {
write_lock_
On 3/4/07, Kyle Moffett <[EMAIL PROTECTED]> wrote:
Well, even this far into 2.6, Linus' patch from 2003 still (mostly)
applies; the maintenance cost for this kind of code is virtually
zilch. If it matters that much to you clean it up and make it apply;
add an alarmfd() syscall (another 100 lines
Please don't take this the wrong way, Ray, but I don't think _you_
understand the problem space that people are (or should be) trying to
address here.
Servers want to always, always block. Not on a socket, not on a stat,
not on any _one_ thing, but in a condition where the optimum number of
conc
On 3/2/07, Davide Libenzi wrote:
For threadlets, it might be. Now think about a task wanting to dispatch N
parallel AIO requests as N independent syslets.
Think about this task having USEDFPU set, so the FPU context is dirty.
When it returns from async_exec, with one of the requests being become
On 2/28/07, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
130 lines skipped...
Yeah, I edited it down a lot before sending it. :-)
I have only one question - wasn't it too lazy to write all that? :)
I'm pretty lazy all right. But occasionally an interesting problem
(and revamping AIO is ver
On 2/27/07, Theodore Tso <[EMAIL PROTECTED]> wrote:
I think what you are not hearing, and what everyone else is saying
(INCLUDING Linus), is that for most programmers, state machines are
much, much harder to program, understand, and debug compared to
multi-threaded code. You may disagree (were y
On 2/25/07, Trent Waddington <[EMAIL PROTECTED]> wrote:
On 2/26/07, Michael K. Edwards <[EMAIL PROTECTED]> wrote:
> I know it's fun to blame everything on Redmond, but how about a
> simpler explanation?
Says the master of conspiracy.
Yes, I rather chuckled at the ir
On 2/25/07, Alan <[EMAIL PROTECTED]> wrote:
> Busy-wait loops were a rhetorical flourish, I grant you.
Thats a complicated fancy way of saying you were talking rubbish ?
No, it's a way of saying "yes, there are deliberate performance limits
in the driver code, but they're harder to explain tha
On 2/25/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
Fundamentally a kernel thread is just its
EIP/ESP [on x86, similar on other architectures] - which can be
saved/restored in near zero time.
That's because the kernel address space is identical in every
process's MMU context, so the MMU doesn't
On 2/25/07, Alan <[EMAIL PROTECTED]> wrote:
> of other places too. Especially when the graphics chip maker explains
> that keeping their driver source code closed isn't really an attempt
> to hide their knowledge under a bushel basket. It's a defensive
> measure against having their retail marg
On 2/25/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
Ok, but this is not realistic. I agree that if Evil Linker only adds
two hooks "void pop_server_starting(), void pop_server_stopping()", he
can get away with that.
But... how does situation change when Evil Linker does #include
from his
binary
On 2/24/07, Davide Libenzi wrote:
Ok, roger that. But why are you playing "Google & Preach" games to Ingo,
that ate bread and CPUs for the last 15 years?
Sure I used Google -- for clickable references so that lurkers can
tell I'm not making these things up as I go along. Ingo and Alan have
ob
On 2/23/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> This is a fundamental misconception. [...]
> The scheduler, on the other hand, has to blow and reload all of the
> hidden state associated with force-loading the PC and wherever your
> architecture keeps its TLS (maybe not the whole TLB, but n
On 2/23/07, Michael K. Edwards <[EMAIL PROTECTED]> wrote:
which costs you a D-cache stall.) Now put an sprintf with a %d in it
between a couple of the syscalls, and _your_ arch is hurting. ...
er, that would be a %f. :-)
Cheers,
- Michael
-
To unsubscribe from this list: send th
Russell, thanks again for offering to look at this; the more oopses
and soft lockups I see on this board, the more I think you're right
and we have an IRQ handling race.
Here's the struct irqchip setup:
/* mask irq, refer ssection 2.6 under chip 8618 document */
static void mv88w8xx8_mask_irq(un
I wrote:
(On a pre-EABI ARM, there is even a substantial
cache-related penalty for encoding the syscall number in the syscall
opcode, because you have to peek back at the text segment to see it,
which costs you a D-cache stall.)
Before you say it, I'm aware that this is not directly relevant to
On 2/23/07, Zach Brown <[EMAIL PROTECTED]> wrote:
I'd love to see a generic implementation of RCU hashing that
subsystems can then take advantage of. It's long been on the fun
side of my todo list. The side I never get to :/.
There's an active thread on netdev about implementing an RCU hash.
Thanks for taking me at least minimally seriously, Alan. Pretty
generous of you, all things considered.
On 2/23/07, Alan <[EMAIL PROTECTED]> wrote:
That example touches back into user space, but doesnt involve MMU changes
or cache flushes, or tlb flushes, or floating point.
True -- on an arch
On 2/23/07, Alan <[EMAIL PROTECTED]> wrote:
> Do you not understand that real user code touches FPU state at
> unpredictable (to the kernel) junctures? Maybe not in a database or a
We don't care. We don't have to care. The kernel threadlets don't execute
in user space and don't do FP.
Blocked
OK, having skimmed through Ingo's code once now, I can already see I
have some crow to eat. But I still have some marginally less stupid
questions.
Cachemiss threads are created with CLONE_VM | CLONE_FS | CLONE_FILES |
CLONE_SIGHAND | CLONE_THREAD | CLONE_SYSVSEM. Does that mean they
share thre
On 2/22/07, Alan <[EMAIL PROTECTED]> wrote:
> to do anything but chase pointers through cache. Done right, it
> hardly even branches (although the branch misprediction penalty is a
> lot less of a worry on current x86_64 than it was in the
> mega-superscalar-out-of-order-speculative-execution da
On 2/22/07, Alan <[EMAIL PROTECTED]> wrote:
> Oh yeah? For IRIX in 1991? Or for that matter, for Linux/ARM EABI
> today? Tell me, how many of what sort of users do you support
Solaris (NTL - very large ISP/Telco), Dec server 5000 (for fun), Irix (and
linux cross for Irix removal), MIPS embedd
On 2/22/07, Alan <[EMAIL PROTECTED]> wrote:
> compiler people caught on to the economic opportunity. Ever pay $5K
> for a CD full of GNU binaries for a commercial UNIX? I did, after
No because I just downloaded them. Much easier and since they are GPL I
was allowed to do so, then rebuilt them
On 2/22/07, D. Hazelton <[EMAIL PROTECTED]> wrote:
> If you take the microsoft windows source code and compile it yourself
> believe me you will get sued if you ship the resulting binaries and you
> will lose in court.
"misappropriation of trade secrets" as well as copyright infringement
But
On 2/22/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
Secondly, even assuming lots of pending requests/async-threads and a
naive queueing model, an open request will eat up resources on the
server no matter what.
Another fundamental misconception. Kernel AIO is not for servers.
One programmer in
On 2/22/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> It is not a TUX anymore - you had 1024 threads, and all of them will
> be consumed by tcp_sendmsg() for slow clients - rescheduling will kill
> a machine.
maybe it will, maybe it wont. Lets try? There is no true difference
between having a 're
On 2/22/07, Oleg Verych <[EMAIL PROTECTED]> wrote:
> Yes, I will go back and read the code for myself. This will take me
> some time because I have only a hand-waving level of knowledge about
> task_structs and pt_regs, and have largely avoided the dark corners of
> the x86 architecture.
This a
On 2/21/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
the syslet/threadlet framework has been derived from Tux, which one can
accuse of may things, but which i definitely can not accuse of being
slow. It has no relationship whatsoever to Solaris 2.0 or later.
So how well does Tux fare on a NUMA bo
On 2/21/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> [...] As for threadlets, making them kernel threads is not such a good
> design feature, O(1) scheduler or not. You take the full hit of
> kernel task creation, on the spot, for every threadlet that blocks.
> [...]
this is very much not how t
On 2/21/07, D. Hazelton <[EMAIL PROTECTED]> wrote:
Actually, on re-reading the GPL, I see exactly why they made that pair of
exceptions. Where it's quite evident that a small to mid scale parsers that
could have been written *without* the use of Bison is clearly a
non-derivative work - Bison was
On 2/21/07, D. Hazelton <[EMAIL PROTECTED]> wrote:
On Wednesday 21 February 2007 19:28, Michael K. Edwards wrote:
> I think you just misread. I said that the Evil Linker has cheerfully
> shipped the source code of the modified POP server. He may not have
> given you the compiler
On 2/21/07, Michael K. Edwards <[EMAIL PROTECTED]> wrote:
You won't be able to do it later if you don't design for it now.
Don't reinvent the square wheel -- there's a model to follow that was
so successful that it has killed all alternate models in its sphere.
Namely,
On 2/21/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
threadlets (and syslets) are parallel contexts and they behave so -
queuing and execution semantics are then ontop of that, implemented
either by glibc, or implemented by the application. There is no
'pipeline' of requests imposed - the structure
On 2/21/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
pthread_cancel() [if/once threadlets are integrated into pthreads] ought
to do that. A threadlet, if it gets moved to an async context, is a
full-blown thread.
The fact that you are proposing pthread_cancel as a model for how to
abort an unfini
On 2/21/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
threadlets, when they dont block, are just regular user-space function
calls - so no need to schedule or throttle them. [*]
Right. That's a great design feature.
threadlets, when they block, are regular kernel threads, so the regular
O(1) sc
Are you using an unpatched gcc 4.1.1? Its optimizer did nasty things
to us, at least on an ARM target ...
-
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
Plea
I think you just misread. I said that the Evil Linker has cheerfully
shipped the source code of the modified POP server. He may not have
given you the compiler he compiled it with, wihout which the source
code is a nice piece of literature but of no engineering utility; but
that's the situation
On 2/21/07, Nuno Silva <[EMAIL PROTECTED]> wrote:
I can see that your argument is all about the defenition of a
"derivative work".
Far from it. Try reading to the end.
We all know that #include is mostly non copyrightable, so I
mostly agree that some - very very simple - modules may not nee
On 2/21/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
I believe this threadlet concept is what user-space will want to use for
programmable parallelism.
This is brilliant. Now it needs just four more things:
1) Documentation of what you can and can't do safely from a threadlet,
given that it run
Actually, it's quite clear under US law what a derivative work is and
what rights you need to distribute it, and equally clear that
compiling code does not make a "translation" in a copyright sense.
Read Micro Star v. Formgen -- it's good law and it's funny and
readable.
I've drafted summaries fr
On 2/19/07, Robert Hancock <[EMAIL PROTECTED]> wrote:
How do you propose to do this? Drivers can get loaded and unloaded at any
time. If you have a device generating spurious interrupts on a shared IRQ
line, there's no way you can use any device on that line until that interrupt
is shut off. Requ
On 2/19/07, Russell King <[EMAIL PROTECTED]> wrote:
This can't happen because when __do_irq unmasks the interrupt source,
the CPU mask is set, thereby preventing any further interrupt exceptions
being taken. This is done precisely to prevent this situation happening.
If you are seeing recursion
And for those reading along at home, _surely_ you understand the
meanings of "ambiguities in an offer of contract must be construed
against the offeror", "'derivative work' and 'license' are terms of
art in copyright law", and "not a valid limitation of scope". If not,
I highly recommend to you t
On 2/19/07, Trent Waddington <[EMAIL PROTECTED]> wrote:
that's what I figured yes, as you're obviously not interested in
convincing anyone of your opinions, otherwise you wouldn't mind
repeating yourself when someone asks you a simple question.
No, dear, I'm just not interested in convincing yo
On 2/19/07, Trent Waddington <[EMAIL PROTECTED]> wrote:
Hang on, you're actually debating that you have to abide by conditions
of a license before you can copy a copyright work?
Please, tell us the names of these appellate court decisions so that
we can read them and weep.
Can we put the games
On 2/19/07, Russell King <[EMAIL PROTECTED]> wrote:
I think something else is going on here. I think you're getting
an interrupt for the UART, and another interrupt is also pending.
Correct. An interrupt for the other UART on the same IRQ.
When the UART interrupt is handled, it is masked at
On 2/19/07, Trent Waddington <[EMAIL PROTECTED]> wrote:
Of course, now you're going to argue that there's no such thing as an
"incompatible license" or "mere aggregation" and that these are just
words that were made up for the GPL, so they can be ignored.. another
pointless semantic argument beca
On 2/19/07, Trent Waddington <[EMAIL PROTECTED]> wrote:
On 2/20/07, Michael K. Edwards <[EMAIL PROTECTED]> wrote:
> Bah. Show us a citation to treaty, statute, or case law, anywhere in
> the world, Mr. Consensus-Reality.
It's a given.. are you seriously contending
On 2/19/07, Russell King <[EMAIL PROTECTED]> wrote:
> setup_irq() is where things go wrong, at least for us, at least on
> 2.6.16.x. Interrupts are not disabled at the point in request_irq()
> when the interrupt controller is poked to enable the IRQ source. If
> you're lucky, and you're on an a
On 2/19/07, Trent Waddington <[EMAIL PROTECTED]> wrote:
If you can't even agree on that the legal concept of a combined work
exists then you're obviously too far from reality for anyone to reason
with.
Bah. Show us a citation to treaty, statute, or case law, anywhere in
the world, Mr. Consensu
On 2/19/07, linux-os (Dick Johnson) <[EMAIL PROTECTED]> wrote:
FWIW. A license is NOT a contract in the United States, according to
contract law. A primary requirement of a contract is an agreement. A
contract cannot, therefore, be forced. Licenses, on the other hand,
can be forced upon the user
On 2/19/07, Russell King <[EMAIL PROTECTED]> wrote:
On Mon, Feb 19, 2007 at 12:37:00PM -0800, Michael K. Edwards wrote:
> What we've seen on our embedded ARM is that enabling an interrupt that
> is shared between multiple UARTs, at a stage when you have not set up
> all
What we've seen on our embedded ARM is that enabling an interrupt that
is shared between multiple UARTs, at a stage when you have not set up
all the data structures touched by the ISR and softirq, can have
horrible consequences, including soft lockups and fandangos on core.
You will be vulnerable
On 2/19/07, Alan <[EMAIL PROTECTED]> wrote:
> jurisdiction. Copyright infringement is a statutory tort, and the
> only limits to contracting away the right to sue for this tort are
> those provided in the copyright statute itself. A contract not to sue
> for tort is called a "license".)
I'd in
Eensy weensy follow-up. No screed. Well, maybe just a _little_ screed.
On 2/18/07, Oleg Verych <[EMAIL PROTECTED]> wrote:
Ulrich Drepper is known to be against current FSF's position on glibc
licence changing.
Will that stop the FSF? Will it stop Red Hat, MontaVista, or
CodeSourcery? Even
On 2/18/07, Davide Libenzi wrote:
Clets would execute in userspace, like signal handlers,
or like "event handlers" in cooperative multitasking environments
without the Unix baggage
but under the special schedule() handler.
or, better yet, as the next tasklet in the chain after the softirq
On second thought, let's not deconstruct this. It's too much work,
and it's a waste of time. Because if you can't read "anything other
people wrote is fair game, but what we write is sacred; our strategy
is to cajole when we can and strong-arm when we can't, and the law be
damned" into that, no
ant to the _engineering_ of the kernel,
but it is (or ought to be) relevant to people's beliefs about whether
EXPORT_SYMBOL_GPL is the right thing to do.
On 2/17/07, Trent Waddington <[EMAIL PROTECTED]> wrote:
On 2/18/07, Michael K. Edwards <[EMAIL PROTECTED]> wrote:
> If
On 2/17/07, Neil Brown <[EMAIL PROTECTED]> wrote:
Suppose someone created a work of fiction titled - for example -
"Picnic at Hanging Rock". And suppose further that this someone left
some issues unresolved at the end of the story, leaving many readers
feeling that they wanted one more chapter t
On 2/17/07, Giuseppe Bilotta <[EMAIL PROTECTED]> wrote:
Which shows how that case is different from writing Linux drivers. For
example, looking at the example the OP was himself proposing a few
alternative approaches to work around the limitation they were hitting:
could just switch to static maj
On 2/17/07, Dave Neuer <[EMAIL PROTECTED]> wrote:
I think you are reading Lexmark wrong. First off, Lexmark ruled that
scenes a faire applied to the toner-level calculation, not "make a
toner cartridge that works with a particular Lexmark printer." It was
the toner-calculation algorithm that coul
On 2/17/07, Scott Preece <[EMAIL PROTECTED]> wrote:
Well, compilation is probably equivalent to "translation", which is
specifically included in the Act as forming a derivative work.
Nix. "Translation" is something that humans do. What's governed by
copyright is the creative expression contai
On 2/15/07, Gene Heskett <[EMAIL PROTECTED]> wrote:
[ignorant silliness]
There is no one to my knowledge here, who would not cheer loudly once a
verdict was rendered because that courts decision would give the FOSS
community a quotable case law as to exactly what is, and is not legal for
you to d
On 2/15/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
Michael K. Edwards wrote:
> Bzzzt. The whole point of the GPL is to "guarantee your freedom to
> share and change free software--to make sure the software is free for
> all its users."
No, that's the FSF marketi
On 2/15/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
v j wrote:
> So far I have heard nothing but, "if you don't contribute, screw you."
> All this is fine. Just say so. Make it black and white. Make it
It is black and white in copyright law and the GPL.
The /whole point/ of the GPL is to funnel
On 2/15/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
Would it make the interface less cool? Yeah. Would it limit it to just a
few linked system calls (to avoid memory allocation issues in the kernel)?
Yes again. But it would simplify a lot of the interface issues.
Only in toy applications. Re
I sympathize with you, VJ, I really do, but you're going to have to do
a lot more homework in order to understand what is happening to Linux
in embedded space. Allow me to supply some worthless, non-lawyer,
non-measurable-kernel-contributor observations, which are at least
quite different from th
1 - 100 of 117 matches
Mail list logo
