Robert Morris wrote:
> The short version is that the Intel Pro/1000 seems to be a lot faster
> than the Alteon Tigon-II or the SysKonnect card for small (60-byte)
> packets. The Intel card can send or receive at least 500,000 60-byte
> packets per second (about 1/3 of a gigabit/second). On the oth
Alan Cox wrote:
> Add a 'preserved' tag for one section of module memory. On load look up the
> data, if its from this boot memcpy it into the module. On unload write it
> back to disk. No kernel code needed.
I like! No kernel code, yet no races or delay.
As written that removes the possibiliti
Richard B. Johnson wrote:
> If you designed it with just one call-gate, with one entry point,
> you would have exactly what we have now except you would execute
> a `call CALL_GATE` instead of `int 0x80`. This turns out to be
> 6 of one and 1/2 dozen of another when it comes to performance.
The f
Alfred Perlstein wrote:
> > If a programmer does not ever wish to block under any circumstances, it's
> > his obligation to communicate this desire to the implementation. Otherwise,
> > the implementation can block if it doesn't have data or an error available
> > at the instant 'read' is called,
Simon Kirby wrote:
> And you'd need to take the descriptor out of the read() set in the
> select() case anyway, so I don't really see what's different.
The difference is that taking a bit out of select()'s bitmap is
basically free. Whereas the equivalent with events is a bind_event()
system call
This text is about how edge-triggered events can work, but they must be
the right kind of edges if they are to be efficient. With suggestions.
Simon Kirby wrote:
> What happens at "wait until output is ready for writing then goto 6"?
> You mean you would stop the main loop to wait for a single c
Simon Kirby wrote:
> > While an 'edge-trigger' design is indeed simpler, I feel that it
> > ends up making the job of the application harder. A simple example
> > to illustrate the point: what if the application does not choose
> > to read all the data from an incoming packet? The app now has
Horst von Brand wrote:
> > > How about first finding out why their buggy JRE detects whether an
> > > address is local by trying to bind() to it :-)
>
> > I don't know why the JRE does it, but I've seen that sort of thing used
> > to decide whether to try X shared memory.
>
> Could you explain t
John Levon wrote:
> should get_module_symbol() die ?
Please no. I use it for a situation where two drivers can be used
independently. However, when they're loaded at the same time they
communicate. Having a third module _just_ to work out how the devices
are related (based on PCI bus topology)
David S. Miller wrote:
> How about first finding out why their buggy JRE detects whether an
> address is local by trying to bind() to it :-)
I don't know why the JRE does it, but I've seen that sort of thing used
to decide whether to try X shared memory.
-- Jamie
-
To unsubscribe from this list:
[EMAIL PROTECTED] wrote:
> > Sounds like you got caught by the conditional move instruction that is
> > generated for 686. It causes oops on 586, and somewhere in the oops or
> > printk code you hit another cmove. Double fault, kernel hang.
>
> Ah yes, it all comes back to me now :)
> Also expl
Linus Torvalds wrote:
> > The assembler doesn't use nops for alignment -- it inserts longer
> > instructions that are effectively nops, either 1 or two. For larger
> > stretches, the assembler inserts a jmp itself for alignment.
>
> Note that some of them are not very good no-ops. At least at so
Andreas Dilger wrote:
> Having a SIGDANGER handler is good for 2 reasons:
> 1) Lets processes know when memory is short so they can free needless cache.
> 2) Mark process with a SIGDANGER handler as "more important" than those
>without. Most people won't care about this, but init, and X, and
Albert D. Cahalan wrote:
> X, and any other big friendly processes, could participate in
> memory balancing operations. X could be made to clean out a
> font cache when the kernel signals that memory is low. When
> the situation becomes serious, X could just mmap /dev/zero over
> top of the backgr
Linus Torvalds wrote:
> You can also still do the stack pointer plaything by just using
> indirection: and when you context switch you switch the pointer around at
> the base of the per-cpu interrupt stack.
Indirection, à la "current = *(stack & ~8191)" might not be a bad idea
in general. As Ral
Andi Kleen wrote:
> > 1. Move the error_code block from divide_error to page_fault;
> >this removes one jump from the page_fault path.
>
> It is not clear that it is worth it. You want to align error_code and
> page_fault to 16 or 32 bytes bytes at least, and it would need to execute
> some n
Kurt Garloff wrote:
> I could not agree more. Normally, you'd better kill a foreground task
> (running nice 0) than selecting one of those background jobs for some
> reasons:
> * The foreground job can be restarted by the interactive user
> (Most likely, it will be only netscape anyway)
> * The
[EMAIL PROTECTED] wrote:
> Looking at the [network] code, I don't see any places where "current"
> is not valid.
> Got some examples?
Damn I'm being dense tonight. No, that bug was due to calling "current"
from the wrong process context, not from an invalid context.
(Self-flagellate, self-flagg
Kenn Humborg wrote:
> My feeling is that interrupt code has no business calling current(),
> but I don't know the kernel well enough to be sure. Is there any
> interrupt-level code that calls current() or is it a design
> principle that it cannot be called?
It's a design principle that you must
Henning P. Schmiedehausen wrote:
> >Hey, colour ls is _useful_!
> Use white background Xterm. Come again?
Ugh!
> One of the biggest mistakes RH ever did was happily jumping off _that_
> cliff to follow SuSE.
Colour ls predates both Red Hat and SuSE.
-- Jamie
-
To unsubscribe from this list: se
Keith Owens wrote:
> >Put __attribute__ ((section (".data"))) into __tcp_clean_cacheline_pad
> >and it should do what you want.
> >
> >Heck, section ".bss" might give you the alignment without the allocation
> >but I'm not as confident about that.
>
> Call me mad but you could actually try this i
David S. Miller wrote:
>> These items are specifically placed into the data section, not the
>> BSS, because these alignment games are not possible in the BSS.
>
>That would mean the BSS needs support alignment games.
>
> The problem is it doesn't work, please go try it.
> So until i
Philip J. Mucci wrote:
> Basically, reading the counters is a 2 step process: read the mmapped
> virtual counters and add that to the contents of rdpmc(). This means
> that (at least for the x86 series) the kernel interface only needs to
> 'guard' access to the MSR to make sure the user doesn't se
Alexander Viro wrote:
> ITYM "cute". As in "cute dancing paperclip". As colourized ls.
Hey, colour ls is _useful_!
> Or --ignore-fail-on-non-empty as rmdir option. Or "let's replace config
> files with directories full of one-liners since packagers can't be arsed
> to learn sed(1)" religion. Sig
Bernhard Rosenkraenzer wrote:
> > Hah! Even the preprocessor is broken in 2.96. I have to use an older one.
>
> Broken in what way? Testcase?
This is the worst:
#define half(x) ((x) / 2)
#define apply(...) apply2 (__VA_ARGS__)
#define apply2(f,x) f (x)
apply (half, X)
Expand
Bernhard Rosenkraenzer wrote:
> > Which still makes it an broken, experimental, unreleased and unofficial
> > compiler, with all the consequences I said.
>
> I agree about the "unreleased and unofficial" part, but it's not quite
> that broken and experimental. Everything that is shipped with Red
Horst von Brand wrote:
> I'd call emacs consistently not being able to start an ls on a 16Mb machine
> much worse than a surprise...
>
> Hint: Think about how emacs would go about doing that...
vfork ;-)
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the b
Peter Osterlund wrote:
> Btw, does anyone know how the seek time depends on the seek distance
> on modern disk hardware?
I know very little but I've seen it before on this list.
For larger seeks, the head is accelerated then decelerated to roughly
the right track. That time is approx. the squar
[EMAIL PROTECTED] wrote:
> > Or go the beancounter route: process 1 asks "can I pin 20 pages", gets
> > told "yes", and goes allocating them, blocking as necessary until it
>
> So you have a "pre-allocation allocator"? Leads to interesting and
> hard to detect bugs with old code that does not pr
[EMAIL PROTECTED] wrote:
> > [EMAIL PROTECTED] wrote:
> > >walk = out;
> > > while(nfds > 0) {
> > > poll_table *tmp = (poll_table *) __get_free_page(GFP_KERNEL);
> > > if (!tmp) {
> >
> > Shouldn't this be GFP_USER? (Which would also conveniently fix
[EMAIL PROTECTED] wrote:
>walk = out;
> while(nfds > 0) {
> poll_table *tmp = (poll_table *) __get_free_page(GFP_KERNEL);
> if (!tmp) {
Shouldn't this be GFP_USER? (Which would also conveniently fix the
problem Victor's pointing out...)
-- Jamie
-
To
Michel Lanners wrote:
> >> static inline int pci_enable_device(struct pci_device *dev)
> >> {
> >>return pci_enable_device_features(USE_IO|USE_MM);
> >> }
> (snip)
> > And what about other features ?
> > I mean:
> > - Bus Master
> > - Memory Write and Invalidate
> > - Parity Error response
>
Julian Anastasov wrote:
> I'm talking about test8. __SI_CODE is in 2.4, not in 2.2.
> The handling is very different. We can't wait for si_code==SI_SIGIO
> in 2.4 anymore. SI_SIGIO is used only in 2.2:fs/fcntl.c. 2.4 stores
> POLL_xxx in si_code instead of SI_SIGIO.
Why does it do that? si
Andrea Arcangeli wrote:
> int * p;
> [...]
> spin_lock(&lock);
> a = *p;
> spin_unlock(&lock);
>
> spin_lock(&lock);
> b = *p;
> spin_unlock(&lock);
> [With "memory" clobber"] the [second] reload of the address of `p'
> isn't necessary and gcc is
Linus, please think this over before applying Andi's patch.
Andi Kleen wrote:
> The problem is really that SI_SIGIO is negative, but it should be positive
> to make SI_FROMUSER return false on it.
This is an old problem. There was a thread on this topic last March.
Look for "accept() improveme
Linus, please think this over before applying Andi's patch.
Andi Kleen wrote:
> The problem is really that SI_SIGIO is negative, but it should be positive
> to make SI_FROMUSER return false on it.
This is an old problem. There was a thread on this topic last March.
Look for "accept() improveme
H. Peter Anvin wrote:
> Ideally, the linker should have some kind of merging pass to merge
> these multiple instances -- this really could help C++ template
> instantiation problems as well -- but for now, the only "safe" way is
> pretty much to provide a library with non-inlined versions and hope
[EMAIL PROTECTED] wrote:
> If we played some "zippy" music that would add to the "feel". Of
> course, we could actually use benchmarks instead.
Benchmarks, famed for their universal appeal :-)
> And, to me, if kernel compiles take longer, I don't care how fast it "feels".
A kernel compile _by i
[EMAIL PROTECTED] wrote:
> > Sure the global system is slower. But the "interactive feel" is faster.
>
> Let's pop up little buttons to make it "feel" faster.
If little buttons pop up quickly when I click on them, then yes that's
better interactive feel. Sometimes the disk is involved in this.
Martin Josefsson wrote:
> I've been trying to get my machine to swap but that seems hard with this
> new patch :) I have 0kB of swap used after 8h uptime, and I have been
> compiling, moving files between partitions and running md5sum on files
> (that was a big problem before, everything ended up
Trond Myklebust wrote:
> > It would not be reasonable to try extending ext2 to 64-bit
> > times, but milliseconds might be doable. You'd need 4 bytes to
> > support the 3 standard time stamps.
>
> > Going to microseconds would require 8 free bytes, which I don't
> > think
Felix von Leitner wrote:
> The kernel interface seems to be:
>
> * supply an O_DIRECTORY flag to open()
O_DIRECTORY means "refuse to open if not a directory".
Old kernels ignore the flag.
So Glibc then calls fstat() to check it's really a directory.
(opendir() is required to fail on non-direc
Jamie Lokier wrote:
> > @touch /usr/people/ralf/src/linux/linux/include/asm/sn/sn0/arch.h
> > [...]
> .cvsignore
Oops, ignore me 'cos I obviously didn't read what I replied to.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-ke
Ralf Baechle wrote:
> >From some random Linux source tree's .hdepend:
> /usr/people/ralf/src/linux/linux/include/asm/sn/sn0/ip27.h: \
>/usr/people/ralf/src/linux/linux/include/asm/mipsregs.h \
>/usr/people/ralf/src/linux/linux/include/asm/sn/addrs.h
> @touch /usr/people/ralf/src/li
Andrea Arcangeli wrote:
> >Andrea - latency is time measured and perceived. Doing it time based
> >seems to make reasonable sense. I grant you might want to play with
> >the weighting per [device]
Right. Perception.
> When you have a device that writes a request every two seconds you still
> wa
Theodore Y. Ts'o wrote:
>> I've told Linus several times about this problems but he puts out one
>> test release after the other without this fixed.
>
>This is kinda important, I run DNS tools which are threaded amongst
>numerous other threaded programs a lot. What needs to be do
Jes Sorensen wrote:
> So? I have one of those letters in my name as well, doesn't mean I put
> it in the From line or in the code that I write. Or do you want us all
> to start using a compiler and editors that will understand full UTF8
> so everybody who use non roman character sets have their na
Dave Zarzycki wrote:
> Personally speaking, I always thought it would be nice if the kernel
> flushed dirty buffers right before a disk spins down. It seems silly to me
> that a disk can spin down with writes pending.
Absolutely. That allows more time spun down too.
-- Jamie
-
To unsubscribe fr
Todd wrote:
> While I agree with what's going on right now, the recent purchase of
> Alteon by Nortel (primarily for their switch line, not for the
> NICs) leaves quite a bit of doubt in my mind about the future of the card
> and the openness of the firmware in particular.
Why not raise your conc
Larry McVoy wrote:
> No matter what you do with rsync, there is no bloody way you can even
> come close to a single 32K disk read and then a 6K over the wire transfer.
> At least, I can't think of one, can you?
rsync will transfer a bunch of file modification times and, where they
don't match, a
Jes Sorensen wrote:
> It took me a little while in the beginning to convince Alteon to open
> up and provide docs, but since they saw the light they have been
> extremely helpful and went much further in their openness than I had
> ever expected or dared to hope for.
And now it's really showing i
David A. Gatwood wrote:
> > I'd love to see a filesystem feature where I could efficiently identify
> > "changed files", where "changed" is defined by last time this application
> > checked or something similar.
>
> An in-filesystem revision number would do the trick. Could be REALLY
> efficient
Larry McVoy wrote:
> We thought about this too (filesystems are where I got into kernel hacking),
> but dismissed it as a Linux only solution. As much as I'd like it to be
> otherwise, BK is not a Linux only product. Whatever we do needs to work on
> NT (shudder) as well as all the dinosaur Unix
Larry McVoy wrote:
> We have a hack in BK for this, at least I think we do, where we can look at
> the time stamps to notice that you haven't modified the files. We don't
> use it because of NFS screwing up timestamps. I suppose we could enable
> it on a per repository basis so that if you knew
Larry McVoy wrote:
> That's a benefit [for BK] of having changesets, I only need to compare
> the ChangeSet file to know that 4 files were updated 2 were moved, and
> 5 were created, then I move those *portions* of those files across the
> wire.
What happens when I lose the ChangeSet file, or mis
David A. Gatwood wrote:
> I'm sorry, but I can't believe those numbers. It takes longer than 1.6
> seconds to stat all the kernel directories unless the BK machine has a
> huge disk cache. It sounds like the BK server was a much more powerful
> machine.
Use treescan for fast stat preload :-) A
Larry McVoy wrote:
> On the other hand, if you do a
>
> find . -type f | xargs touch
> time cvs update .
>
> it will melt down your DSL line for what seems forever. I killed it after
> 20 minutes, I have better things to do with my bandwidth. It's pretty
> clear that CVS is comparing
Rik van Riel wrote:
> The main difference between Linux and Netware here is the
> fact that Linux has a real userland, which can touch the
> pages on its own without going through the kernel.
>
> This causes "spontaneously" dirtied or accessed pages,
> meaning that we really want to use the hardw
Larry McVoy wrote:
> > Development:
> > In addition, by maintaining the system in CVS we can offer much
> > faster and convenient source updates than are currently available
> > from other Linux-based systems currently available.
>
> Err, "faster"? The following is the mo
Jeff V. Merkey wrote:
> One of the best references that describes the bus transaction model for
> Intel in "plain english" is the Pentium Pro Processor System
> Architecture Manual by Tom Shanley of Mindshare, Inc., Addison Wesley,
> ISBN: 0-201-47953-2. It explains a very good detail how the ca
Rik van Riel wrote:
> > The person writing and updating page table entries in NetWare
> > 4.1 was clearing the accessed bit in the PTE and did not know
> > that the processor would assert a hidden R/M/W operation and
> > assert a bus lock to set this bit everytime someone cleared it
> > -- it made
Jeff V. Merkey wrote:
> This means it completely unnecessary to assert LOCK# for the unlock
> case, since there are no ordering issues persay - the other processors
> are spinning on the lock already and cannot get through.
Yes I know I left out the context. Doesn't change what I'm about to
say.
Lars Marowsky-Bree wrote:
> > I still don't see how processor traces will tell me what ordering
> > guarantees I can rely on across the range of processors.
>
> It will tell you when your assumptions were wrong.
Indeed. Like testing, but better.
-- Jamie
-
To unsubscribe from this list: send t
Jeff V. Merkey wrote:
> The best info I know of is to get an analyser that plugs into the
> processor socket (like an american arium) and enable branch trace
> messaging to monitor the interaction between the processor and the cache
> controllers. You get info that's not in any Intel book just wa
> I won't use a Linus example in the future since this seems to turn off
> some folks reason centers and they go into "attack mode".
Thanks Jeff, I heard that.
I got a lot of useful info from that 3 week long thread, but it's still
a bit confusing. A decent document from Intel or their competit
Jeff V. Merkey wrote:
> To cite a Linux specific example, let's take the issue with the memory
> write for a spin_unlock(). Linus seemed to have trouble grasping why
> a simple ' mov , 0' would work as opposed to a 'lock dec
> '
No logic analyser will tell you the subtleties of _why_ it works.
Y
Michael Elizabeth Chastain wrote:
> A source control system so that curious people could do the equivalent of
> "cvs annotate" and figure out who wrote particular pieces?
Note convinced about "cvs annotate". Maybe annotation with version
numbers. But "cvs diff" and "cvs update" are very use
Graham Murray wrote:
> "David S. Miller" <[EMAIL PROTECTED]> writes:
>
> > The authors of rfc793 probably, in all honesty, really meant
> > "must be set to zero by current implementations".
>
> I agree, to me it seems obvious that the reason is so that these bits
> could be used at some time in
Albert D. Cahalan wrote:
> > You can say it louder but you can't say it clearer. I'd love to know that
> > my surname shows up correctly everywhere. BTW, mutt shows MIME
> > patches in plain text without any problems
>
> That would be the "H=F8jland" in your .sig, right?
> No problem, '=' is
Linus Torvalds wrote:
> It's about the fact that when I chose the GPL, I did it because I wanted
> the source-code to be free and unencumbered. Forever. Whether I maintained
> that code or not. I didn't want my code to have any extra rules and
> regulations - the GPLv2 is already quite complex eno
Russell King wrote:
> > With laptops, people are willing
> > to assume the RAM is reliable -- accidentally pulling the plug out won't
> > lose the data.
>
> But a buggy apm implementation and the battery running down can.
Well, perhaps the risk is worth it.
-- Jamie
-
To unsubscribe from this l
Alan Cox wrote:
> Every line of code I wrote is under the GPLv2 or later (except those bits
> I contributed that were BSD non advertising derived and which I left the BSD
> license on).
By the way, the tiny amounts of code from me that are in there are GPLv2
or later too. (Do we need a copyrigh
Russell King wrote:
> > *a silent hard disk hard disk is no longer feasible since kernel
> > 2.2.11*.
>
> Yes it is. I have one of my machines (which NFS serves a NFS root
> client, both of which are on 24 hours a day) capable of spinning
> down for up to 4 hours at a time, with no kernel modifi
Andrea Arcangeli wrote:
> >BTW Look also into asm-i386/bitops.h and dummy cast to some crap there.
> >Are you impressed? 8)
>
> Yep 8). If we add "memory" such stuff could be removed I think. As far I
> can see the object of such stuff is to cause gcc to say `I'm too lazy to
> see exactly what me
Ingo Molnar wrote:
> > They seem focused on keeping us in the dark ages. We need tools to make
> > it faster and easier for folks to perform kernel development and make
> > field support of Linux easier.
>
> tools can sometimes bring the dark ages faster than anything else.
However, if Jeff w
[EMAIL PROTECTED] wrote:
> > Well, now GCC does CSE across "asm" and will eliminate memory loads,
> > even though it may not move them! I suspect it always did CSE across
> > "asm" and we just never got hit by the bug.
>
> dummy_lock trick is equivalent to "memory" clobber.
For GCC 2.7.2 yes.
Andrea Arcangeli wrote:
> >Well, now GCC does CSE across "asm" and will eliminate memory loads,
>
> What is "CSE"?
Common Subexpression Elimination.
If the compiler sees an expression equivalent to one it evaluated
earlier, there is no need to evaluate it a second time.
So "a = x+x; b = x+x" w
Andrea Arcangeli wrote:
> >int *p;
> >int func()
> >{
> > int x;
> > x = *p;
> > __asm__ __volatile__ ("" : : : "memory");
> > x = *p;
> > return x;
> >}
>
> Defintely none difference here (-fstrict-aliasing doesn't change anything
> either).
>
> andrea@inspiron:~ > gcc -v
> Reading specs f
Andrea Arcangeli wrote:
> Said that if your compiler puts the read before the spin_lock without the
> memory clobber, it is allowed to do that, and in such case you would proof
> it was a real world bug (not just a "documentation" one).
Yes, it does.
> Or maybe your testcase was a bit different
Linus Torvalds wrote:
> Nope. "memory" fills that role too. Remember: "memory" doesn't actually
> say "this clobbers all memory". That would be silly: an asm that just
> wipes all memory would not be a very useful asm (or rather, it would have
> just _one_ use: "execve()"). So "memory" really says
[EMAIL PROTECTED] wrote:
> Just hint. I remember the time when "memory" clobber option
> was _absent_ in gcc. And we managed to compile kernel with such gcc. 8)
> To all that I understand, "asm" (like function calls) implied barrier
> that time and constraints and clobber option were used only for
Timur Tabi wrote:
> Well, if it really is just his hobby, then he shouldn't be chanting
> the "World Domination" mantra.
Why not? World Domination is my hobby too :-)
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Linus Torvalds wrote:
> Change it to something like
>
> __asm__("":"=r" (x):"0" (x));
>
> and the "volatile" should matter.
Yes it does. Without "volatile", the asm disappears :-)
> Not for memory references, perhaps. But for the movement issues.
The compiler isn't moving memory refere
Linus Torvalds wrote:
> "volatile" should be equivalent to clobbering memory, although the gcc
> manual pages are certainly not very verbose on the issue.
It isn't. Try the following with/without the memory clobber:
int *p;
int func()
{
int x;
x = *p;
__asm__ __volatile__ ("" : : : "memor
Andrea Arcangeli wrote:
> >>int a = *p;
> >>__asm__ __volatile__("" : :);
> >>a = *p;
> >>
> >> (to do two explicit reads)
> >
> >Sorry, that does just one read, kgcc (old stable gcc) and also with
> >gcc-2.96. Type aliasing on/off makes no difference to the number of reads.
>
> I w
asm *__volatile__* seems to make no difference. I've tried a few things.
Andrea Arcangeli wrote:
> Maybe we can rely on the __volatile__ statement of the asm that will
> enforce that if we write:
>
> *p = 0;
> __asm__ __volatile__("" : :);
> *p = 1;
>
> in the assembler we'll
David Woodhouse wrote:
> But how much work would it require to do so? If your theoretical vendor of
> closed-source compiler backends were to believe that a shared lib of the
> GCC frontend would be legal, surely they'd just make it shared themselves,
> then use it as such? It's hardly a effect
David Woodhouse wrote:
> You cannot safely compile even 2.4 kernels with gcc-2.96 on any platform, as
> far as I'm aware. It's an insane thing to do. Use a sensible compiler.
Oh. I've been using gcc-2.96 with test7 for a while, no problems except
the ## warnings. Never occured to me that gcc-2.
Alan Cox wrote:
> I've spent over 2 years trying to extract eepro100 server docs out of Intel
> and failed.
Sounds familiar :-)
According to group legend here (I wasn't around but will repeat what I
was told), we spent about 1 year trying to get docs on Intel's i960
based gigabit card so we coul
dean gaudet wrote:
> suppose you're building a threaded server to scale to 20k connections,
> and you want to support fork()/exec() of CGIs dirctly (rather than
> through a separate daemon process).
>
> if you don't use close-on-exec, then after fork before exec you have
> to iterate over the 20k
Chris Wedgwood wrote:
> I think would be really cool if all this 'magic' in gcc (whatever
> part of gcc is irrelevant right now) would be exported into a library
> or shared object which editors could then load and use... dynamically
> perhaps.
Sorry, there's a GCC policy decision against putting
Linus Torvalds wrote:
> And I'm saying that if people really want to do this, then use the
> computer to do it for you, having more than just "grep", and making your
> tools aware of it.
I'd just like to add, for the benefit of onlookers, that this is
quite easy.
Temporarily change name of `coun
Chris Wedgwood wrote:
[Gcc not eliminating trivial dead code...
did you compile without optimisation?]
Gcc 2.96 does remove the unreached code in your example,
but it still emits string constants.
int func()
{
if (1)
a = "foo";
else
a = "bar";
}
.LC0:
.string "foo"
.LC1:
You know, some of us have mail filters installed for us without our
consent or knowledge...
At least, I noticed (some weeks later) when mail from some of my friends
was being rejected (policy reject) by my main email account... bah,
bah, complain, complain.
-- Jamie
-
To unsubscribe from this
Petko Manolov wrote:
> > You'd still want string-486.h to _call_ the larger routines in
> > string-486.c, using FASTCALL or your choice of alternate registers.
>
> I am not very sure if Linus will like the idea.
There is precedent: arch/i386/mmx.c.
I expect he'd prefer it over inlining unrolled
Ricky Beam wrote:
> >Tell me, would you like this done to you? You may assume typical
> >corporate enhancements: no PGP, filter runs on Windows 2000, any
> >unknown headers get stripped out, etc.
>
> ... message size restrictions, attachment mangling, false virus detection...
... restricted From
Ricky Beam wrote:
> As an aside, they also have/had agressive transparent web proxying in
> the network... everything on port 80 coming and going is/was cached.
> EVERYTHING.
That's quite nice when it works, but sometimes the proxy breaks. Then
it really _sucks_.
You fetch a page and get a blan
Petko Manolov wrote:
> I don't see the point of string-486.c - string-486.h is a replacement
> of string.h for i[45]86 machines so let stay in include directory.
The point is it may run faster due to better i-cache usage. Remember
also that 486 machines don't have much memory, so the gain from r
Alan Cox wrote:
> > Alan, can you send me again the list of CPUs you think
> > is worth using 486 string routines.
> > Sorry, i lost your previous mail.
>
> I suspect it is
>
> 486
> K5
> IDT Winchip
> Rise
> NexGen
Take a look at
http://now.cs.berkeley.edu/Td/b
Linus Torvalds wrote:
> (The "invalidate on write" is the sane way of doing SMP cache coherency,
> which is probably why. Trying to have shared dirty cache-lines is just
> not a viable option in the end).
With DMA from a device -- "snoop and update" still results in only one
owner of the dirty ca
201 - 300 of 316 matches
Mail list logo
