On Thu, 2 Nov 2000, Alan Cox wrote:
> > xfree 4.0.1d supports it, but the screen flicker so hard, that is is
> > unusable.
>
> Ah there is a trick to that bit. If you have some i810 stuff then XFree does
> funnies if you have DRM enabled.
I did disable loading drm/dri module from
On Thursday 02 November 2000 02:40, Vojtech Pavlik wrote:
> On Thu, Nov 02, 2000 at 12:01:09AM -0500, Jeff Garzik wrote:
> > Please grab 1.1.14, there were a number of bug fixes since 1.1.10. You
> > can get this version in the recently-released 2.4.0-test10 kernel, or
> > download from
On Thu, Nov 02, 2000 at 02:27:35PM -0700, Tim Riker wrote:
> #pragma is a particularly difficult problem to deal with because it is
> non macro friendly. =(
>
> Sounds like C99 initializers are a likely first target for integration.
>
> I'll keep plugging away at other stuff here as well.
I've
Okay I just want a reason to post:
"That Dirty Son of a Bitch, Bill Gates!!!"
Cheers,
Andre Hedrick
Linux ATA Development
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at
On Thu, Nov 02, 2000 at 11:55:52PM +, Alan Cox <[EMAIL PROTECTED]> wrote:
> > - If I'm correct that pipes have a 4K kernel buffer, then writing 1
> > byte shouldn't cause this situation, as the buffer is well more than
> > half empty. Is this still a bug?
>
> The pipe code uses totally
On Fri, Nov 03, 2000 at 12:38:18AM -0500, Frank Davis wrote:
> Hello,
> Its a parody page from someone in LateSky Omaha, Nebraska, USA .
> Regards,
> -Frank
Yup, I especially like the "Microsoft Invades Cuba" and "Microsoft
Monkey Colony on Mars" headlines on that page...
/David
_
"Jeff V. Merkey" wrote:
> A "context" is usually assued to be a "stack". The simplest of all
> context switches is:
>
>movx, esp
>movesp, y
Is that your two instruction context switch? The problem is, it doesn't
transfer control anywhere. Maybe it doesn't need to. I guess
On Thu, Nov 02, 2000 at 07:38:56PM +0100, Ragnar Hojland Espinosa wrote:
> On Thu, Nov 02, 2000 at 06:57:06PM +0100, Ragnar Hojland Espinosa wrote:
> > Well, here never did until today :) With test9, I had left the box idle
>
> Just happened with test10, same circumstances .. font map got
On Thu, 2 Nov 2000, David Ford wrote:
> Dan Hollis wrote:
> > On Thu, 2 Nov 2000, David Ford wrote:
> > > Ok, something happend to the tulip driver in the recent testN kernels.
> > > I haven't found a reason why it happens and I can't easily reproduce it
> > > but what happens is noted on the
Dan Hollis wrote:
> On Thu, 2 Nov 2000, David Ford wrote:
> > Ok, something happend to the tulip driver in the recent testN kernels.
> > I haven't found a reason why it happens and I can't easily reproduce it
> > but what happens is noted on the subject line.
> > I have three machines now that
Ok, something happend to the tulip driver in the recent testN kernels.
I haven't found a reason why it happens and I can't easily reproduce it
but what happens is noted on the subject line.
I have three machines now that do this. It's unfixable until reboot (I
don't have these as modules).
I
On Thu, 2 Nov 2000, Jens Axboe wrote:
> On Thu, Nov 02 2000, Val Henson wrote:
> > > > 3) combine this with the elevator starvation stuff (ask Jens
> > > >Axboe for blk-7 to alleviate this issue) and you have a
> > > >scenario where processes using /proc//stat have the
> > > >
> > Semantic issues aside, since Apache does the test I mentionned earlier
> > to determine child status and since it could be misled, should this
> > feature be turned off?
>
> Or made smarter yes
i'm scratching my head wondering what i was thinking when i wrote that
code. the specific thing
Hello,
Its a parody page from someone in LateSky Omaha, Nebraska, USA .
Regards,
-Frank
--On Thursday, November 02, 2000 9:13 PM -0800 Andre Hedrick <[EMAIL PROTECTED]>
wrote:
>
> http://mslinux.org
>
> Andre Hedrick
> Linux ATA Development
>
> -
> To unsubscribe from this list: send the line
Hello Andre , A ;-) is at least due on that one .
actually quite funny in many places . Thanks for the fun .
JimL
On Thu, 2 Nov 2000, Andre Hedrick wrote:
> http://mslinux.org
> Andre Hedrick
http://mslinux.org
Andre Hedrick
Linux ATA Development
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
It shows that even though select() says a file descriptor is not
writable, a write() can still succeed. This code is not used anywhere
in the real world, or at least my real world :-P. It just demonstrates
"the bug".
Richard B. Johnson" wrote:
> Not as I see it. This is clearly a code bug.
> > - Changing /sbin/hotplug invocations ... now it can
> > only support "add" and "del" events. (USB now
> > uses "add" and "remove", though "remove" doesn't
> > try to do anything yet.)
> >
> > This removes the intended flexibility whereby
> > different
--- "Richard B. Johnson" <[EMAIL PROTECTED]>
wrote:
> Using an IP packet of 255.255.255.255 doesn't mean
> it's a broadcast
> packet. It is going to your default gateway because
> it is outside
> your netmask, which guarantees that it is not a
> broadcast.
1) No, it's still a broadcast packet
On Thu, Nov 02 2000, Mike Dresser wrote:
> I'm currently running 2.4.0test10, running backups onto an IDE HP 7/14
> gb drive. Using tar -cpvf /dev/ht0 myfiles backs up fine, no errors.
>
> But..
>
> promise:~# tar -tf /dev/ht0
> tar: /dev/ht0: Cannot read: Input/output error
> tar: At
This patch allows the real mode setup code to check for required
features (such as cmov, pae, etc.) that would normally just cause the
boot process to silently hang. Tested with a K6-2 (no cmov) and an
Athlon (has cmov), needs testing on a CPU without cpuid.
--
Rob Landley <[EMAIL PROTECTED]> writes:
> --- Jeff Garzik <[EMAIL PROTECTED]> wrote:
> > Rob Landley wrote:
> > > Under 2.2.16, broadcast packets addressed to
> > > 255.255.255.255 do not go out to all interfaces in
> > a
> > > machine with multiple network cards. They're
> > getting
> > >
On Thu, Nov 02 2000, David Mansfield wrote:
> Hi Jens.
>
> I wanted to try out blk-7 to see if it cured the abysmal I/O
> performance on 2.4.0-test10, but it won't boot on my system.
Could you try blk-8?
*.kernel.org/pub/linux/kernel/people/axboe/patches/2.4.0-test10/blk-8.bz2
It also has
>
Thank you for the information.
I will give it some thought and see if I can come up
with something that will fit both bills...
The problem is that the disks that I have are
very wide-spread, I would imagine. Compaq is shipping
them in their
"chen, xiangping" wrote:
>
> Hello,
>
> I met a problem when trying to upgrade my Linux kernel to 2.4.0-test10.
> The machine is Compay AP550, dual processor, mem 512 MB, and 863 MHZ freq.
> It has two scsi host adaptors. one is AIC-7892 ultra 160/m connected to
> internal hard disk, and the
Anyone having a problem with the ADMtek Comet TX lockups, please contact
me. I believe I have found a fix but need some people to test it.
Details of this bug can be found here:
http://www.tux.org/hypermail/linux-tulip-bug/2000-Oct/0012.html
-Dan
-
To unsubscribe from this list: send the line
--- Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Rob Landley wrote:
> > Under 2.2.16, broadcast packets addressed to
> > 255.255.255.255 do not go out to all interfaces in
> a
> > machine with multiple network cards. They're
> getting
> > routed out the default gateway's interface
> instead.
>
>
On Thu, 2 Nov 2000, Paul Marquis wrote:
> In the code sample, there is a loop that is run four times. During
> each iteration, a call to select() and write() is done, while every
> other iteration does a read(). Between the 1st and 2nd calls to
> write(), as well as the 3rd and 4th, select()
Short answer UHCI JE does work for me, no more strange errors...
The weird thig is that I have used 2.2 USB backports since the begining,
but I have always used the other UHCI, and up till now it used to work for
me, except for now, but now it seems to be ok w/ the JE variant.
Thanks for the
On Thu, Nov 02, 2000 at 06:24:47PM -0600, Elizabeth Morris-Baker wrote:
> >
>
> Yes, I know that is in the spec, but truly,
> some scsi devices do act this way
> Maybe they need to read the spec :>
>
> I have included the START_STOP for Matthew, but
> I never
Hi,
The problem got solved by replacing the AHA-3944 card to
AIC-7895, thus switching the order of SCSI discovery.
It seems that still a SCSI ordering problem.
Thanks any way!
Xiangping
-Original Message-
From: Elizabeth Morris-Baker [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November
Bunch of sysctl bugs:
* use of proc_dostring with ->strategy==NULL instead of systcl_string.
* use of sysctl_intvec with NULL ->extra1 and ->extra2 (harmless, but silly).
Patch follows. Please, apply.
Cheers,
>
Yes, I know that is in the spec, but truly,
some scsi devices do act this way
Maybe they need to read the spec :>
I have included the START_STOP for Matthew, but
I never see it execute with the ATLAS disks...
A diff follows for those that
David Brownell wrote:
> - Changing /sbin/hotplug invocations ... now it can
> only support "add" and "del" events. (USB now
> uses "add" and "remove", though "remove" doesn't
> try to do anything yet.)
>
> This removes the intended flexibility whereby
>
> What fb driver would support it?
I seen a i810 fbdev driver before but I haven't see any updates to it in a
awhile.
> does vga16 support 1024x768?
No. vga16 supports standard vga graphics modes (ie 640x480 16 colors).
-
To unsubscribe from this list: send the line "unsubscribe
Rob Landley wrote:
> Under 2.2.16, broadcast packets addressed to
> 255.255.255.255 do not go out to all interfaces in a
> machine with multiple network cards. They're getting
> routed out the default gateway's interface instead.
Are the network cards on the same network?
--
Jeff Garzik
On Thu, Nov 02 2000, Val Henson wrote:
> > > 3) combine this with the elevator starvation stuff (ask Jens
> > >Axboe for blk-7 to alleviate this issue) and you have a
> > >scenario where processes using /proc//stat have the
> > >possibility to block on multiple processes that are in
> We'd like to have two sets of keyboard/mouse/screen connected to the
> same computer with each set having the control and output of an
> independent X
> session each, concurrently. There might for instance be the ps/2
> keyboard and mouse and
> USB dittos. After attempting (and failing) we
On Fri, Nov 03, 2000 at 02:08:53AM +0100, Sasi Peter wrote:
> On Thu, 2 Nov 2000, Greg KH wrote:
>
> > Could you send the result of /proc/interrupts and 'lspci -v'?
> > Also, have you tried the alternate UHCI controller driver?
> > Or tried USB as modules, instead of compiled in?
>
> Here you
On Fri, Nov 03, 2000, Sasi Peter <[EMAIL PROTECTED]> wrote:
> On Thu, 2 Nov 2000, Greg KH wrote:
>
> > Could you send the result of /proc/interrupts and 'lspci -v'?
> > Also, have you tried the alternate UHCI controller driver?
> > Or tried USB as modules, instead of compiled in?
>
> Here you
> Console colors are completely messed up (read: black, I even suspect
> the font to be corrupt somehow) if switching back to console mode
> from X (either by quitting or ctrl-alt-fX) in recent 2.4.0-textXX
> kernels. 2.2.XX do work just fine. Is this a known problem with a
> known fix?
How
> I have a similar hardware list and I don't observe any of these problems on
> 2.4.0-test10x. Is it possibly a hardware conflict somewhere?
>
> What I do see occasionally is if X was ever heavy on the memory usage (say
> I've run GIMP for a couple of hours) then the text console's font set
On Thu, 2 Nov 2000, Greg KH wrote:
> Could you send the result of /proc/interrupts and 'lspci -v'?
> Also, have you tried the alternate UHCI controller driver?
> Or tried USB as modules, instead of compiled in?
Here you go. I did work w/ the very same hw with pre15.
I have never really knew
> Has anyone considered the possibility of expanding the buffer of
> high-traffic pipes?
Do that too much and the data falls out of L1 cache before we context switch.
Its a rather complex juggling game. DaveM's kiovec pipe patches avoid some of
this by cheating and going user->user
-
To
Under 2.2.16, broadcast packets addressed to
255.255.255.255 do not go out to all interfaces in a
machine with multiple network cards. They're getting
routed out the default gateway's interface instead.
If I ifconfig eth1 down (which has the gateway behind
it), I start getting "no route to
I'm glad to see the CardBus/PCI and network hotplug
support start happening!
Would you motivate two changes I noticed?
- Changing /sbin/hotplug invocations ... now it can
only support "add" and "del" events. (USB now
uses "add" and "remove", though "remove" doesn't
try to
Followup to: <[EMAIL PROTECTED]>
By author:Paul Marquis <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> Okay, I see your point, thanks. A couple of comments/questions:
>
> - Does this make sense with devices with small kernel buffers? From
> my experimentation, pipes on Linux have
> - Does this make sense with devices with small kernel buffers? From
> my experimentation, pipes on Linux have a 4K buffer and tend to be
> read and written very quickly.
It makes sense for all things I suspect
> - If I'm correct that pipes have a 4K kernel buffer, then writing 1
> byte
The SCSI spec says that INQUIRY and not
TUR + INQUIRY is the way to go, but maybe we
should make it a compile time option for buggy
drives.
On Thu, Nov 02 2000, Elizabeth Morris-Baker wrote:
> >
>
> You need to send the TUR first, but yes,
> START_STOP will guarantee that you are
Okay, I see your point, thanks. A couple of comments/questions:
- Does this make sense with devices with small kernel buffers? From
my experimentation, pipes on Linux have a 4K buffer and tend to be
read and written very quickly.
- If I'm correct that pipes have a 4K kernel buffer, then
> > I'm seeing this as well, but only with PIII Xeon systems, not PII
> > Xeon. Every single timer interrupt on any CPU is accompanied by a NMI
> > and LOC increment on every CPU.
> >
> >CPU0 CPU1
> > 0: 146727 153389IO-APIC-edge timer
> > [...]
> > NMI:
Hi,
Thanks for replying. What bothers me is that it works
in another pc with the same setup to the external disk,
but different internal scsi adaptor. So I did not think
it was the kernel software caused the problem. Any other
guess?
Thanks,
Xiangping
-Original Message-
From:
[1.] One line summary of the problem:
Kernel 2.4.0-test10 Multiple oops
[2.] Full description of the problem/report:
When running dselect from Debian Woody, after all the packages were
downloaded, it began to install them, and then oopsed twice. The system
seemed normal after words, but
Ted
Agreed. C99 does not replace all the needed gcc features. We should
start using the ones that make sense, and push for
standardization/documentation on the rest.
I'm perfectly happy with this as a long term goal. I'll put what effort
I can into moving that direction without breaking the
> I'm not exactly sure what you mean by this statement. Would you mind
> explaining further?
Well take a socket with 64K of buffering. You don't want to wake processes
waiting in select or in write every time you can scribble another 1460 bytes
to the buffer. Instead you wait until there is 32K
On Thu, Nov 02, 2000 at 03:15:17AM +0100, J . A . Magallon wrote:
> "Includes" means that the full patch is not included in pre18 ?.
Only the strict bugfix broadcasted to l-k is been included in pre18.
> So, will the VM-pre17 work with pre18 ?.
It will generate a trivial reject but I just
On Thu, Nov 02, 2000 at 05:39:03PM +, Dr. David Gilbert wrote:
> > So, here is David's mtrr patch. Although in his case ("only" 4G) it
> > shouldn't be needed it is for 36bit MTRRs I assume.
>
> Thanks! That patch did the trick - our machine is now running lovely.
Your very rare
I'm not exactly sure what you mean by this statement. Would you mind
explaining further?
Alan Cox wrote:
> Most fast devices wake up when buffers are half empty for example.
--
Paul Marquis
[EMAIL PROTECTED]
If it's tourist season, why can't we shoot them?
-
To unsubscribe from this list:
>
You need to send the TUR first, but yes,
START_STOP will guarantee that you are
ready to rock and roll.
The first fix I wrote did a TUR, then
3 tries at a START_STOP, till it worked.
cheers,
Elizabeth
>
>
Davide Libenzi wrote:
>
> On Thu, 02 Nov 2000, Jeff V. Merkey wrote:
> > "Jeff V. Merkey" wrote:
> > This code fragment will generate an AGI condition:
> >
> > mov eax, addr
> > mov [eax].offset, ebx
>
> I had already posted the correction.
> It was clear that You had forgot something coz
In the code sample, there is a loop that is run four times. During
each iteration, a call to select() and write() is done, while every
other iteration does a read(). Between the 1st and 2nd calls to
write(), as well as the 3rd and 4th, select() fails, but all write()'s
and read()'s succeed.
On Thu, 02 Nov 2000, Jeff V. Merkey wrote:
> "Jeff V. Merkey" wrote:
> This code fragment will generate an AGI condition:
>
> mov eax, addr
> mov [eax].offset, ebx
I had already posted the correction.
It was clear that You had forgot something coz Your old code fragment did not
generate
> I guess in theory, you're right, though if a write() could succeed,
> shouldn't select() say that it would?
Thats certainly not normal for a lot of devices. Most fast devices wake up
when buffers are half empty for example.
Alan
-
To unsubscribe from this list: send the line "unsubscribe
On Thu, Nov 02, 2000 at 03:58:24PM -0600, Elizabeth Morris-Baker wrote:
> Basically the problem is in scan_scsis_single.
> Some scsi devices are notoriously brain dead
> about answering inquiries without having
> recived a TUR and then spinning up.
> The problem
I guess in theory, you're right, though if a write() could succeed,
shouldn't select() say that it would?
And this assumes you're calling select() with a timeout. In Apache,
the caretaker process wakes up periodically and polls the pipe with a
timeout of zero. If it gets back the pipe is not
"Jeff V. Merkey" wrote:
In the example of an AGI generating code fragment, while I described the
sequence of creating the AGI with immediate address usage correctly
(i.e. if you load an address into a register then immediately attempt to
use it, it will generate an AGI), I failed to put the
Date: Thu, 02 Nov 2000 13:53:55 -0700
From: Tim Riker <[EMAIL PROTECTED]>
As is being discussed here, C99 has some replacements to the gcc syntax
the kernel uses. I believe the C99 syntax will win in the near future,
and thus the gcc syntax will have to be removed at some point.
On Thu, 2 Nov 2000, Alan Cox wrote:
> > that are log file handlers are dead. If select() reports it can't
> > write immediately, Apache terminates and restarts the child process,
> > creating unnecessary load on the system.
>
> Is there anything saying that select has to report ready the
"D. Hugh Redelmeier" wrote:
> Being GCC-dependent is rather parochial. Being GCC-version-dependent
> is downright embarrassing.
>
> Summary: spurious GCC-isms are a bad thing.
Summary: You have no clue about kernel<->gcc interdependencies and
issues.
> - use ISO C 89 when possible (without
> that are log file handlers are dead. If select() reports it can't
> write immediately, Apache terminates and restarts the child process,
> creating unnecessary load on the system.
Is there anything saying that select has to report ready the instant a byte
would fit. Certainly its better for
Arjan van de Ven wrote:
> [snip]
>
> > CONFIG_M686=y
>
> Ah ha!
>
> You have selected the Pentium II/III CPU type, which does NOT work on a K6.
> The compiler (and the kernel) will use the "new" Pentium II instructions
> (such as "cmov") which are not supported by the K6, leading to "illegal
| From: Tim Riker <[EMAIL PROTECTED]>
| However, it makes me a bit nervous to take this route. It assumes that
| the way gcc does things is the "best way". A more formal route of adding
| to the ANSI C standard would involve more eyes and therefore hopefully
| add to the quality of what has been
>
> Hello,
Yes, I encountered the same problem, and have a fix, but
want to test it. If the author of scsi_scan.c would like
to correct it, then that would be fine.
Basically the problem is in scan_scsis_single.
Some scsi devices are notoriously brain
I've uncovered a bug in select() when checking if it's okay to write
on a pipe. It will report "false negatives" if there is any unread
data already on the pipe, even a single byte. As soon as the pipe
gets flushed, select() does the right thing.
Normally, I wouldn't think this such a big
Hi!
I see that gcc-2.7.2 is unusable for compiling kernel, because of
named initializers problems.
What is status of egcs-2.90.29 980515 (egcs-1.0.3 release)? Are there
known bugs preventing it from compiling kernel?
Pavel
--
I'm
On Thu, Nov 02, 2000 at 08:19:06AM +0100, Mike Galbraith wrote:
> On Wed, 1 Nov 2000, Rik van Riel wrote:
>
> > I have one possible reason for this
> >
> > 1) the procfs process does (in fs/proc/array.c::proc_pid_stat)
> > down(>mmap_sem);
> >
> > 2) but, in order to do that, it has
[recipients list shortened]
At 17:28 01/11/2000, Jeff V. Merkey wrote:
>Anton Altaparmakov wrote:
> > IMHO stability is more important than anything else. - I prefer to run 20
> > Linux servers which will result in no phonecalls at midnight calling me
> > into College to reboot them compared to a
Hello,
I met a problem when trying to upgrade my Linux kernel to 2.4.0-test10.
The machine is Compay AP550, dual processor, mem 512 MB, and 863 MHZ freq.
It has two scsi host adaptors. one is AIC-7892 ultra 160/m connected to
internal hard disk, and the other is AHA-3944 ultra scsi connected to
On Thu, Nov 02 2000, David Mansfield wrote:
> Hi Jens.
>
> I wanted to try out blk-7 to see if it cured the abysmal I/O
> performance
> on 2.4.0-test10, but it won't boot on my system. The last message I
> see
> is the banner of the SCSI host adapter init (it found the card) but
> it
Excellent. I guess I really need to get a copy of the C99 spec
and dig through it.
http://webstore.ansi.org/ansidocstore/product.asp?sku=ANSI%2FISO%2FIEC+9899%2D1999
Thanx!
GCC does have a table of what's been implemented so far:
http://www.gnu.org/software/gcc/c99status.html
Which indicates
On Thu, Nov 02, 2000 at 02:27:35PM -0700, Tim Riker wrote:
> #pragma is a particularly difficult problem to deal with because it is
> non macro friendly. =(
When you assume C99 it is no problem, because C99 has _Pragma()
-Andi
-
To unsubscribe from this list: send the line "unsubscribe
#pragma is a particularly difficult problem to deal with because it is
non macro friendly. =(
Sounds like C99 initializers are a likely first target for integration.
I'll keep plugging away at other stuff here as well.
Andi Kleen wrote:
>
> On Thu, Nov 02, 2000 at 09:17:44PM +, Alan Cox
Do you or anyone else on the list recall why this decision was made? Can
you recall around when it was made so I can dig out the history from the
archives?
I would be eager to convert everything over to the C99 syntax, test the
heck out of it and submit the patch. Obviously this is wasted effort
On Thu, Nov 02, 2000 at 09:17:44PM +, Alan Cox wrote:
> > How can I insure that the largest possible amount of my efforts benefit
> > the community at large? Hopefully this will make it easier to move to
> > C99 or any other future compiler porting project.
>
> The asm I dont know - its a
On Thu, Nov 02, 2000 at 11:26:18AM +0100, Sasi Peter wrote:
> Hi!
>
> Seems like something in USB went wrong from pre15, I get something like
> what is in the attachment.
>
> I have tried using HID + mouse, HID BP, disabling event interface,
> disabling hot-plug support, disabling preliminary
> How can I insure that the largest possible amount of my efforts benefit
> the community at large? Hopefully this will make it easier to move to
> C99 or any other future compiler porting project.
The asm I dont know - its a hard problem. Things like C99 initializers for 2.5
seem quite a
> I am running kernel 2.2.5-15. I am trying to calculate sin(0.9), and it crashes on a
>386 board with no f/p hardware. The message I get is:
>
> "Unable to handle kernel paging request at virtual address 7f3c0070.."
>
> The interesting thing is sin(0.8) works fine. On a Pentium the
Alan,
Alan Cox wrote:
>
> > > That need to run Linux - name one ? Why try to solve a problem when it hasn't
> > > happened yet. Let whoever needs to solve it do it.
> >
> > We have proposals here all under NDA. So I won't mention one of them.
> > Perhaps there are some of these folk on the list
In article <[EMAIL PROTECTED]> you wrote:
> As is being discussed here, C99 has some replacements to the gcc syntax
> the kernel uses. I believe the C99 syntax will win in the near future,
> and thus the gcc syntax will have to be removed at some point. In the
> interim the kernel will either
ok, a very valid point. The "C++ kernel code" reference is very telling.
(ouch). ;-)
Obviously the changes to support non-gcc compilers should have the goal
of minimal impact on gcc users lives. I recognize that the mainstream
will still use gcc.
Q: Why should we help you make it possible to
Hi.
Various parts of the kernel, notably the drivers, have sections
of code that is only relevant if certain defines are valid. The
obvious examples would be CONFIG_PROC_FS and MODULES. In both
cases the functions directly used in conjunction with these
defines evaluate to nops. But especially
A number of people have pointed out to me that egcs-1.1.2 is weak on C++
support. Rather than clutter up the list by replying to all of them, I've
picked this one to say "Thank you" to everyone who responded. I'm not a C++
programmer, so I tend to forget about it and think of gcc as just a C
> > That need to run Linux - name one ? Why try to solve a problem when it hasn't
> > happened yet. Let whoever needs to solve it do it.
>
> We have proposals here all under NDA. So I won't mention one of them.
> Perhaps there are some of these folk on the list that would like to
> comment?
Date:Thu, 02 Nov 2000 12:31:51 -0700
From: Tim Riker <[EMAIL PROTECTED]>
Me or Alan? I did not mean this as a dig. I feel strongly that one
should have the choice here. I do not choose to enforce my beliefs on
anyone else. I am suggesting only that others should provide
The clock on some alpha systems might be at 1200 Hz...
you've rather to use HZ:
--- /usr/src/linux/include/asm-alpha/param.h.orig Wed Nov 1 12:31:56
2000
+++ /usr/src/linux/include/asm-alpha/param.h Wed Nov 1 12:33:22 2000
@@ -27,4 +27,8 @@
#define MAXHOSTNAMELEN 64 /* max
On Thu, Nov 02, 2000 at 01:00:13PM -0700, Tim Riker wrote:
> This started off with some comments from the group (hpa in particular)
> that even between gcc releases, the gcc extensions have been much less
> stable that the standard compiler features. The danger of implementing
Given how the
In article <[EMAIL PROTECTED]> you wrote:
> You also forgot named structure initializers, but C99 supports them
> again with a different syntax than gcc [I guess it would have been too easy
> to just use the gcc syntax]
The named initializers syntax in C99 is from plan9, besides beeing probably
This occurs when the 3c509-module is being loaded at startup, and in
/proc/modules it is listed as (initialising). It it worth mentioning
that I have two 3c509-cards in my computer. This worked in test8.
Unable to handle kernel NULL pointer dereference at virtual address
0070
c6d485a5
On Thu, Nov 02, 2000 at 11:55:55AM -0700, Tim Riker wrote:
> 1. C++ style comments
>
> Occurs in over 4000 lines of source and header files. :-( Should be
> converted to ansi c comments? We will probably want to just skirt this
> issue for now as the next rev of ANSI C is likely to include ANSI
Andrea Arcangeli wrote:
>
> On Thu, Nov 02, 2000 at 12:17:33PM -0700, Tim Riker wrote:
> > [..] by adding gcc
> > syntax into it [..]
>
> I think that's the right path. How much would be hard for you to add gcc syntax
> into your compiler too instead of feeding us kernel patches? Note that it
1 - 100 of 336 matches
Mail list logo
