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/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
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
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
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
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
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 (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, 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, 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, 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, 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, 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/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/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, 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, 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, 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, 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:
> 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
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/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
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, 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.
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
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
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
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/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/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/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, 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:
> 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, 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/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/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/6/07, Joel Becker <[EMAIL PROTECTED]> wrote:
Not everything is in-cache. Databases will be doing O_DIRECT
and will expect that 90% of their I/O calls will block. Why should they
have to iterate this list every time? If this is the API, they *have*
to. If there's an efficient way
Man, I should have edited that down before sending it. Hopefully this
is clearer:
- The usual programming model for AIO completion in GUIs, media
engines, and the like is an application callback. Data that is
available immediately may be handled quite differently from data that
arrives after
An idiot using my keyboard wrote:
- AIO requests that are serviced from cache ought to immediately
invoke the callback, in the same thread context as the caller, fixing
up the stack so that the callback returns to the instruction following
the syscall. That way the "immediate completion" pat
On 2/14/07, Benjamin LaHaise <[EMAIL PROTECTED]> wrote:
My opinion of this whole thread is that it implies that our thread creation
and/or context switch is too slow. If that is the case, improve those
elements first. At least some of those optimizations have to be done in
hardware on x86, whil
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
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
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, 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, 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/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/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, 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, 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
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 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
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
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/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
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, 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
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, 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, 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:
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, 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, 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:
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, 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
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, 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
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
ALSA + GCC 4.1.1 + -Os is known to be a bad combination on some
arches; see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27363 . (I
tripped over it on an ARM target, but my limited understanding of GCC
internals does not allow me to conclude that it is ARM-specific.) A
patch claiming to fix the b
On 1/29/07, Greg KH <[EMAIL PROTECTED]> wrote:
Free Linux Driver Development!
Yes, that's right, the Linux kernel community is offering all companies
free Linux driver development. ...
[snip]
[1] for the CPUs that support the bus types that your device works on.
Bravo! Now, is there a mess
On 1/30/07, Kumar Gala <[EMAIL PROTECTED]> wrote:
Out of interest are you was this geared to any particular SoC's/
architectures?
I had in mind the sort of ARM-, PPC-, and MIPS-based SoCs that wind up
in handhelds, mobiles, set-tops, and consumer-grade WiFi devices.
That's an area I know passab
On 2/1/07, Lennart Sorensen <[EMAIL PROTECTED]> wrote:
Sometimes I might be. At least on the days I have to deal with problems
in Windows (it's not even my machine, so I don't get to pick what it
runs all the time. :) I haven't had particularly much luck getting a
stable wireless going on linux
Sorry, I wrote this:
(This is not an ARM-specific question, although the example is on ARM.)
and then sent it to linux-arm-kernel anyway. :-P
I'm writing an ALSA driver for an ARM SoC whose PCM audio interface is
MMIO. ALSA provides copy_from_user_toio and copy_to_user_fromio
routines for th
Preface: I am aware that other people here know far more that I do
about the details of C semantics. If the inconsistency is deliberate,
please just point me to the previous LKML thread.
On 2/2/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
H. Peter Anvin wrote:
> Jeff Garzik wrote:
>> Volatile is
On 12/5/06, Russell King <[EMAIL PROTECTED]> wrote:
There's not much to say about this, other than scream and go hide in the
corner. ARM toolchains are just basically fscked.
And while we're on the topic of ARM linux toolchain fsckage, it would
be nice to know what patches and incantations are
On 12/5/06, Russell King <[EMAIL PROTECTED]> wrote:
There is no such thing as soft VFP.
Patches have been floating around for quite some time that implement
soft float with VFP parameter passing conventions (which notably
implies native endianness, unlike FPA). They all seem to derive from
Nic
On 12/13/06, Linus Torvalds <[EMAIL PROTECTED]> wrote:
Ok, what kind of ass-hat idiotic thing is this?
C'mon, Linus, tell us how you _really_ feel.
Seriously, though, please please pretty please do not allow a facility
for "going through a simple interface to get accesses to irqs and
memory re
On 12/13/06, Greg KH <[EMAIL PROTECTED]> wrote:
On Wed, Dec 13, 2006 at 12:38:05PM -0800, Michael K. Edwards wrote:
> Seriously, though, please please pretty please do not allow a facility
> for "going through a simple interface to get accesses to irqs and
> memory region
On 12/13/06, Andrew Morton <[EMAIL PROTECTED]> wrote:
On Wed, 13 Dec 2006 13:32:50 -0800
Martin Bligh <[EMAIL PROTECTED]> wrote:
> So let's come out and ban binary modules, rather than pussyfooting
> around, if that's what we actually want to do.
Give people 12 months warning (time to work out
On 12/13/06, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
Aside of that there are huge performance gains for certain application /
driver scenarios and I really don't see an advantage that people are
doing excactly the same thing in out of tree hackeries with a lot of
inconsistent user land interfa
fish for birds alone?
no, teach suits how to leave more
fish to go around
Cheers,
- Michael
-
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 FA
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/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
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, 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
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:
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, 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
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/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
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, 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/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
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, 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
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
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
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
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
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
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
1 - 100 of 117 matches
Mail list logo
