Re: [PATCH] document ECN in 2.4 Configure.help
On Sun, 5 Nov 2000, Barry K. Nathan wrote: +CONFIG_INET_ECN + Explicit Congestion Notification (ECN) allows routers to notify + clients about network congestion, resulting in fewer dropped packets + and increased network performance. This option adds ECN support to the + Linux kernel, as well as a sysctl (/proc/sys/net/ipv4/tcp_ecn) which + allows ECN support to be disabled at runtime. You might mention the RFC here, 2481 IIRC. + Note that, on the Internet, there are many broken firewalls which + refuse connections from ECN-enabled machines, and it may be a while + before these firewalls are fixed. Until then, to access a site behind + such a firewall (some of which are major sites, at the time of this + writing) you will have to disable this option, either by saying N now + or by using the sysctl. I'm still not sure why it's been decided not to do fallback or how this whole situation is any different from path MTU discovery. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
On Mon, 6 Nov 2000, David Woodhouse wrote: On Mon, 6 Nov 2000, Oliver Xymoron wrote: If I understand you correctly: process 1 process 2 ... Is there any reason we ever want to unblock process 1 before process 2 terminates? No, and I don't think we do. That's not the point. 'init module' is still _after_ 'set mixer levels'. There is a period during which the mixer levels are changed. Perhaps you mean before? Otherwise you've lost me. The desired mixer levels should be available to the module at the time of initialisation. Is this because active audio sources other than /dev/dsp writers are suddenly in and out of the mix? If there's nothing on the inputs, it shouldn't matter whether you're changing the levels. The right way to do this (according to any sound engineer) is to initialize all the levels to zero unless told otherwise. This would doubtless annoy the average user, but is more or less equivalent to not forwarding packets by default. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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/
Re: [PATCH] make my life easier ...
On Wed, 25 Oct 2000, Martin Mares wrote: > Hello! > > > "The Linux 'original' IDE guy' Mark Lord showed Alan what was trying to > > bang over everyone's head, without success. > > > > Here is his sample code for cs5530 chipset. > > > > Look at this and comment. I have part of the space setup to complete the > > APM extenstion calls. This will get you and me out of a jam with laptops. > > This doesn't make much sense to me: Why don't we just reinitialize the timings > as we do when programming the chipset instead of saving/restoring the state? > > Also, are you sure BIOSes don't save the IDE controller state when suspending? Assume BIOS = just enough to appear to work with Windows. My VAIO appears to lose at least the spindown timeout setting, probably more on suspend. It also loses some video state - if I suspend when the screen is blanked by X, restore gets me a white screen of death - no way to make video come back to life. Now that I've got hibernate working, I've figured out that I can hibernate/unhibernate to get the card back into the state X thinks it should be in. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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/
Re: [PATCH] make my life easier ...
On Wed, 25 Oct 2000, Martin Mares wrote: Hello! "The Linux 'original' IDE guy' Mark Lord showed Alan what was trying to bang over everyone's head, without success. Here is his sample code for cs5530 chipset. Look at this and comment. I have part of the space setup to complete the APM extenstion calls. This will get you and me out of a jam with laptops. This doesn't make much sense to me: Why don't we just reinitialize the timings as we do when programming the chipset instead of saving/restoring the state? Also, are you sure BIOSes don't save the IDE controller state when suspending? Assume BIOS = just enough to appear to work with Windows. My VAIO appears to lose at least the spindown timeout setting, probably more on suspend. It also loses some video state - if I suspend when the screen is blanked by X, restore gets me a white screen of death - no way to make video come back to life. Now that I've got hibernate working, I've figured out that I can hibernate/unhibernate to get the card back into the state X thinks it should be in. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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/
Re: PC speaker driver patch for 2.4.0-test10-pre3
On Tue, 24 Oct 2000, Pavel Machek wrote: > Hi! > > > > [EMAIL PROTECTED] said: > > > > You can also pretty trivially keep track of an error term so that the > > > > clock is right on average: > > > > > > True, but I don't want 'right on average'. I want 'not screwed with at all'. > > > Shifting the timer tick onto the RTC will give me that. > > > > > > Even if we _do_ get the maths right, fudging with the frequency of the > > > system timer is still an ugly hack. > > > > I personally think the system timer is already an ugly hack. HZ is > > arbitrary, slow by modern standards, and introduces latency. > > As the comment you quoted points out, it's also not very accurate. > > Much better would be an agenda structure with one shot timers between > > events and jiffies based on cycle counters. This works on modern hardware > > and scales well for higher processor speeds. > > ...and breaks horribly when your CPU frequency changes... like on most > current notebooks. The unit of time is arbitrary. Cycle counts just happens to be convenient on most machines and very high resolution. The important point is that hanging tasks off a periodic low-resolution timer is not scaling with CPU clock speeds at all and there are ways to throw it out. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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/
Re: PC speaker driver patch for 2.4.0-test10-pre3
On Tue, 24 Oct 2000, Pavel Machek wrote: Hi! [EMAIL PROTECTED] said: You can also pretty trivially keep track of an error term so that the clock is right on average: True, but I don't want 'right on average'. I want 'not screwed with at all'. Shifting the timer tick onto the RTC will give me that. Even if we _do_ get the maths right, fudging with the frequency of the system timer is still an ugly hack. I personally think the system timer is already an ugly hack. HZ is arbitrary, slow by modern standards, and introduces latency. As the comment you quoted points out, it's also not very accurate. Much better would be an agenda structure with one shot timers between events and jiffies based on cycle counters. This works on modern hardware and scales well for higher processor speeds. ...and breaks horribly when your CPU frequency changes... like on most current notebooks. The unit of time is arbitrary. Cycle counts just happens to be convenient on most machines and very high resolution. The important point is that hanging tasks off a periodic low-resolution timer is not scaling with CPU clock speeds at all and there are ways to throw it out. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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/
Re: PC speaker driver patch for 2.4.0-test10-pre3
On Mon, 23 Oct 2000, David Woodhouse wrote: > > [EMAIL PROTECTED] said: > > You can also pretty trivially keep track of an error term so that the > > clock is right on average: > > True, but I don't want 'right on average'. I want 'not screwed with at all'. > Shifting the timer tick onto the RTC will give me that. > > Even if we _do_ get the maths right, fudging with the frequency of the > system timer is still an ugly hack. I personally think the system timer is already an ugly hack. HZ is arbitrary, slow by modern standards, and introduces latency. As the comment you quoted points out, it's also not very accurate. Much better would be an agenda structure with one shot timers between events and jiffies based on cycle counters. This works on modern hardware and scales well for higher processor speeds. As for the current inaccuracy, the jitter introduced by using an error term can never be more than a single real interrupt cycle, which is already well below the average userspace latency. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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/
Re: PC speaker driver patch for 2.4.0-test10-pre3
On Mon, 23 Oct 2000, David Woodhouse wrote:
> See arch/i386/kernel/time.c:
>
> /* This function must be called with interrupts disabled
> * It was inspired by Steve McCanne's microtime-i386 for BSD. -- jrs
> *
> * However, the pc-audio speaker driver changes the divisor so that
> * it gets interrupted rather more often - it loads 64 into the
> * counter rather than 11932! This has an adverse impact on
> * do_gettimeoffset() -- it stops working! What is also not
> * good is that the interval that our timer function gets called
> * is no longer 10.0002 ms, but 9.9767 ms. To get around this
> * would require using a different timing source.
You can also pretty trivially keep track of an error term so that the
clock is right on average:
#define CLK_HZ 1193200 /* or whatever */
#define ET_PRECISION 1000
#define ET_TIMER_TICKS CLK_HZ*ET_PRECISION/HZ
#define ET_PCSP_TICKS 64*ET_PRECISION
...
static long et=0;
...
et+=ET_PCSP_TICKS;
if(et>ET_TIMER_TICKS) {
et-=ET_TIMER_TICKS;
simulate_timer_tick();
}
This keeps track of the residual timing error to a few decimal places to
several decimal places and will get closer to HZ than even the current
code.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
-
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/
Re: PC speaker driver patch for 2.4.0-test10-pre3
On Mon, 23 Oct 2000, David Woodhouse wrote:
See arch/i386/kernel/time.c:
/* This function must be called with interrupts disabled
* It was inspired by Steve McCanne's microtime-i386 for BSD. -- jrs
*
* However, the pc-audio speaker driver changes the divisor so that
* it gets interrupted rather more often - it loads 64 into the
* counter rather than 11932! This has an adverse impact on
* do_gettimeoffset() -- it stops working! What is also not
* good is that the interval that our timer function gets called
* is no longer 10.0002 ms, but 9.9767 ms. To get around this
* would require using a different timing source.
You can also pretty trivially keep track of an error term so that the
clock is right on average:
#define CLK_HZ 1193200 /* or whatever */
#define ET_PRECISION 1000
#define ET_TIMER_TICKS CLK_HZ*ET_PRECISION/HZ
#define ET_PCSP_TICKS 64*ET_PRECISION
...
static long et=0;
...
et+=ET_PCSP_TICKS;
if(etET_TIMER_TICKS) {
et-=ET_TIMER_TICKS;
simulate_timer_tick();
}
This keeps track of the residual timing error to a few decimal places to
several decimal places and will get closer to HZ than even the current
code.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
-
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/
Re: PC speaker driver patch for 2.4.0-test10-pre3
On Mon, 23 Oct 2000, David Woodhouse wrote: [EMAIL PROTECTED] said: You can also pretty trivially keep track of an error term so that the clock is right on average: True, but I don't want 'right on average'. I want 'not screwed with at all'. Shifting the timer tick onto the RTC will give me that. Even if we _do_ get the maths right, fudging with the frequency of the system timer is still an ugly hack. I personally think the system timer is already an ugly hack. HZ is arbitrary, slow by modern standards, and introduces latency. As the comment you quoted points out, it's also not very accurate. Much better would be an agenda structure with one shot timers between events and jiffies based on cycle counters. This works on modern hardware and scales well for higher processor speeds. As for the current inaccuracy, the jitter introduced by using an error term can never be more than a single real interrupt cycle, which is already well below the average userspace latency. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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/
Re: 2.2 -> 2.4 transition questions
On Sat, 14 Oct 2000, Mike A. Harris wrote: > The 2.4.0test9 Changes file mentions the following and I'd like > to know if after installing updated packages, if I'll still be > able to use a 2.2.x kernel ok, or if I'll have to resort to > initscript trickery: > > Will the following work with 2.2.17 as well? > > o util-linux 2.10o # kbdrate -v > o modutils 2.3.15 # insmod -V > o PPP2.4.0 # pppd --version Debian-unstable has those versions or newer (modutils is .17), but still comes with a 2.2 kernel. And there are a lot of people running unstable. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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/
Re: 2.2 - 2.4 transition questions
On Sat, 14 Oct 2000, Mike A. Harris wrote: The 2.4.0test9 Changes file mentions the following and I'd like to know if after installing updated packages, if I'll still be able to use a 2.2.x kernel ok, or if I'll have to resort to initscript trickery: Will the following work with 2.2.17 as well? o util-linux 2.10o # kbdrate -v o modutils 2.3.15 # insmod -V o PPP2.4.0 # pppd --version Debian-unstable has those versions or newer (modutils is .17), but still comes with a 2.2 kernel. And there are a lot of people running unstable. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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/
Re: large memory support for x86
On Wed, 11 Oct 2000, Kiril Vidimce wrote: > My primary concern is whether a process can allocate more than 4 GB of > memory, rather than just be able to use more than 4 GB of physical > memory in the system. Define allocate. There are tricks you can play, but userspace is still a flat 32-bit address space per-process. > Also, I see that the highmem support is just an option in the kernel. > Does this mean that there is a significant performance penalty in using > this extension? It doesn't come for free, but it's almost certainly a win for anyone who has that much memory. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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/
Re: Updated 2.4 TODO List
On Thu, 12 Oct 2000, Keith Owens wrote: > If anything is going to detect the mismatch and complain, it has to be > the boot loader, after uncompressing and before entering the kernel > proper. Perhaps we can add the processor type to linux_banner and print it from setup.S. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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/
Re: Updated 2.4 TODO List
On Thu, 12 Oct 2000, Keith Owens wrote: If anything is going to detect the mismatch and complain, it has to be the boot loader, after uncompressing and before entering the kernel proper. Perhaps we can add the processor type to linux_banner and print it from setup.S. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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/
Re: large memory support for x86
On Wed, 11 Oct 2000, Kiril Vidimce wrote: My primary concern is whether a process can allocate more than 4 GB of memory, rather than just be able to use more than 4 GB of physical memory in the system. Define allocate. There are tricks you can play, but userspace is still a flat 32-bit address space per-process. Also, I see that the highmem support is just an option in the kernel. Does this mean that there is a significant performance penalty in using this extension? It doesn't come for free, but it's almost certainly a win for anyone who has that much memory. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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/
Re: CVS for kernel
On Wed, 11 Oct 2000, Keith Owens wrote: > Yes. I am usually up to date on pre patches within a few hours of > their release, but then I have to play catch up to get my own patches > up to date. What I would like is the ability to see what is in the > kernel CVS tree before the pre patch is sent out so I can get > modutils/ksymoops/kdb patches ready ahead of the kernel patch release. You're out of luck - Linus doesn't use CVS (at least for the kernel). Perhaps we can convince Alan to do it for 2.2.x and set a precedent.. The closest we can get otherwise is to get HPA to hook CVS into kernel.org's release system so that prepatches get added to public CVS mirrors (cvs.xx.kernel.org?) more or less instantly. Hopefully a tighter feedback loop (and more uptodate patch) from that might eventually convince Linus to make live CVS available. It'd also be nice if we formally adopted a four-digit versioning scheme. The current ..-pre thing kinda sucks because (a b c) > (a b c d). -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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/
Re: CVS for kernel
On Wed, 11 Oct 2000, Keith Owens wrote: Yes. I am usually up to date on pre patches within a few hours of their release, but then I have to play catch up to get my own patches up to date. What I would like is the ability to see what is in the kernel CVS tree before the pre patch is sent out so I can get modutils/ksymoops/kdb patches ready ahead of the kernel patch release. You're out of luck - Linus doesn't use CVS (at least for the kernel). Perhaps we can convince Alan to do it for 2.2.x and set a precedent.. The closest we can get otherwise is to get HPA to hook CVS into kernel.org's release system so that prepatches get added to public CVS mirrors (cvs.xx.kernel.org?) more or less instantly. Hopefully a tighter feedback loop (and more uptodate patch) from that might eventually convince Linus to make live CVS available. It'd also be nice if we formally adopted a four-digit versioning scheme. The current a.b.c-pred thing kinda sucks because (a b c) (a b c d). -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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/
Re: 2.4.0t8 strangeness
On Mon, 25 Sep 2000, Oliver Xymoron wrote: > On my /home partition, mkdir(2) is returning EIO on ext2fs for uid!=0. > Creating files with touch still works though. Persists after reboot, > forced e2fsck finds nothing wrong. > > About to try test9-pre6 but thought I'd mention it. Figured it out. Ran into the reserved block limit, which used to return ENOSPACE? Any chance this could be changed back? -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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/
Re: the new VMt
On Mon, 25 Sep 2000, Alan Cox wrote: > > > > Stupidity has no limits... > > > > > > Unfortunately its frequently wired into the hardware to save a few cents on > > > scatter gather logic. > > > > Since when hardware folks became exempt from the rule above? 128K is > > almost tolerable, there were requests for 64 _mega_bytes... > > Most cheap ass PCI hardware is built on the basis you can do linear 4Mb > allocations. There is a reason for this. You can do that 4Mb allocation on > NT or Windows 9x Sure about that? It's been a while, but I seem to recall NT enforcing a scatter-gather framework on all drivers because it only gave them virtual allocations. For the cheaper cards, the s-g was done by software issuing single span requests to the card. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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/
2.4.0t8 strangeness
On my /home partition, mkdir(2) is returning EIO on ext2fs for uid!=0. Creating files with touch still works though. Persists after reboot, forced e2fsck finds nothing wrong. About to try test9-pre6 but thought I'd mention it. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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/
2.4.0t8 strangeness
On my /home partition, mkdir(2) is returning EIO on ext2fs for uid!=0. Creating files with touch still works though. Persists after reboot, forced e2fsck finds nothing wrong. About to try test9-pre6 but thought I'd mention it. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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/
Re: the new VMt
On Mon, 25 Sep 2000, Alan Cox wrote: Stupidity has no limits... Unfortunately its frequently wired into the hardware to save a few cents on scatter gather logic. Since when hardware folks became exempt from the rule above? 128K is almost tolerable, there were requests for 64 _mega_bytes... Most cheap ass PCI hardware is built on the basis you can do linear 4Mb allocations. There is a reason for this. You can do that 4Mb allocation on NT or Windows 9x Sure about that? It's been a while, but I seem to recall NT enforcing a scatter-gather framework on all drivers because it only gave them virtual allocations. For the cheaper cards, the s-g was done by software issuing single span requests to the card. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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/
Re: 2.4.0t8 strangeness
On Mon, 25 Sep 2000, Oliver Xymoron wrote: On my /home partition, mkdir(2) is returning EIO on ext2fs for uid!=0. Creating files with touch still works though. Persists after reboot, forced e2fsck finds nothing wrong. About to try test9-pre6 but thought I'd mention it. Figured it out. Ran into the reserved block limit, which used to return ENOSPACE? Any chance this could be changed back? -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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/
Re: Is there any T/TCP patch for kernel 2.2.*
On Thu, 21 Sep 2000, Mao Yun wrote: > Hi all, > Is there any T/TCP patch for kernel 2.2.16? thanks. Maybe, but you don't want it. T/TCP is inherently insecure. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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/
Re: [DOC] Debugging early kernel hangs
On Fri, 22 Sep 2000, Keith Owens wrote: > On Thu, 21 Sep 2000 18:54:33 -0400 (EDT), > Byron Stanoszek <[EMAIL PROTECTED]> wrote: > >On Fri, 22 Sep 2000, Keith Owens wrote: > >> The idea is to write characters direct to the video screen during > >> booting using a macro called VIDEO_CHAR. > > > >Why not just redirect printk() to output a string of characters one by one > >using VIDEO_CHAR until the console subsystem is initialized. You can use a > >statically defined int to keep track of what row & column you're on. There is > >no need to be so cryptic about the readout. > > Overhead and difficulty to use from assembler. VIDEO_CHAR() generates > a single mov instruction, calling printk and looping to do output does > a lot more code. You can do the equivalent of VIDEO_CHAR direct from > assembler without disturbing any registers, to call printk means saving > registers around the call and constructing text strings in the > assembler code. It shouldn't be a big deal. It goes from a mov to a push/call. Readability goes up enormously. I wrote a bootloader for an embedded box recently and the first piece I wrote was an asm version of printf, followed by a register dump (named doh). -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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/
Re: [DOC] Debugging early kernel hangs
On Fri, 22 Sep 2000, Keith Owens wrote: On Thu, 21 Sep 2000 18:54:33 -0400 (EDT), Byron Stanoszek [EMAIL PROTECTED] wrote: On Fri, 22 Sep 2000, Keith Owens wrote: The idea is to write characters direct to the video screen during booting using a macro called VIDEO_CHAR. Why not just redirect printk() to output a string of characters one by one using VIDEO_CHAR until the console subsystem is initialized. You can use a statically defined int to keep track of what row column you're on. There is no need to be so cryptic about the readout. Overhead and difficulty to use from assembler. VIDEO_CHAR() generates a single mov instruction, calling printk and looping to do output does a lot more code. You can do the equivalent of VIDEO_CHAR direct from assembler without disturbing any registers, to call printk means saving registers around the call and constructing text strings in the assembler code. It shouldn't be a big deal. It goes from a mov to a push/call. Readability goes up enormously. I wrote a bootloader for an embedded box recently and the first piece I wrote was an asm version of printf, followed by a register dump (named doh). -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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/
Re: Is there any T/TCP patch for kernel 2.2.*
On Thu, 21 Sep 2000, Mao Yun wrote: Hi all, Is there any T/TCP patch for kernel 2.2.16? thanks. Maybe, but you don't want it. T/TCP is inherently insecure. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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/
Re: [RFC] Changes file [was Re: modules directory]
On Tue, 12 Sep 2000, Simon Huggins wrote: > On Tue, Sep 12, 2000 at 01:41:45AM -0500, Oliver Xymoron wrote: > > > > This is similar to my patch-names patch, which lets you add components > > > > to uname too. IIRC, it was rejected because it made things easier. > > > Erm? Not really. Not unless you want > > > 2.2.x-requires-modutils-2.3.9-requires-pppd-x.y.z etc? > > No, that's not it at all. It's more for doing things like > > 2.4.0-pre8+ikd+xfs where ikd and xfs are patches you applied. With a > > little Makefile magic, they become part of the uname. > > Yes, you implied it solved what I was trying to solve being the people > complaining on list about make modules_install no longer working when > they hadn't read Documentation/Changes. The thread had moved on by then to a trick for putting changelog entries in patches. With my patch, you can put the changelog entries in the same files that flag the uname additions. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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/
Re: [RFC] Changes file [was Re: modules directory]
On Mon, 11 Sep 2000, Simon Huggins wrote: > On Sat, Sep 09, 2000 at 11:59:41AM -0500, Oliver Xymoron wrote: > > This is similar to my patch-names patch, which lets you add components > > to uname too. IIRC, it was rejected because it made things easier. > > Erm? Not really. Not unless you want > 2.2.x-requires-modutils-2.3.9-requires-pppd-x.y.z etc? No, that's not it at all. It's more for doing things like 2.4.0-pre8+ikd+xfs where ikd and xfs are patches you applied. With a little Makefile magic, they become part of the uname. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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/
Re: [RFC] Changes file [was Re: modules directory]
On Tue, 12 Sep 2000, Simon Huggins wrote: On Tue, Sep 12, 2000 at 01:41:45AM -0500, Oliver Xymoron wrote: This is similar to my patch-names patch, which lets you add components to uname too. IIRC, it was rejected because it made things easier. Erm? Not really. Not unless you want 2.2.x-requires-modutils-2.3.9-requires-pppd-x.y.z etc? No, that's not it at all. It's more for doing things like 2.4.0-pre8+ikd+xfs where ikd and xfs are patches you applied. With a little Makefile magic, they become part of the uname. Yes, you implied it solved what I was trying to solve being the people complaining on list about make modules_install no longer working when they hadn't read Documentation/Changes. The thread had moved on by then to a trick for putting changelog entries in patches. With my patch, you can put the changelog entries in the same files that flag the uname additions. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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/
Re: Availability of kdb
[reposted for the benefit of anyone wondering what Linus was replying to] On Sat, 9 Sep 2000, Oliver Xymoron wrote: > On Sat, 9 Sep 2000, Linus Torvalds wrote: > > > I use revision control at work. We use CVS on steroids - CVS with a lo tof > > the extensions available, and with a "mad scientists helper" program > > called "igor". > [...] > > And with a chip that _includes_ a compiler, we have some debuggers that I > > don't think exist anywhere else on the planet. Which turns out very useful > > when the first version of the silicon doesn't actually act the way we > > thought it would ;) > > I figured as much on both counts, actually - I was mostly razzing you. > > > So I've seen both. And I still don't think they make for better code. They > > sometimes make for more expedient release schedules. Which is not the same > > thing at all. > > I think the only one who's argued from the release schedule POV is Jeff > Merkey. The rest are arguing that debuggers are sometimes useful tools[1]. > > Tools are tools. They don't make better code. They make better code easier > if used properly. Companies are using drills and lathes and table saws and > power sanders to produce furniture that doesn't compare to antiques made > with hand tools[2]. Does this mean we should make everything by hand? No, > it just means we need to be focused on craftsmanship rather than cost. > I think the current development culture already has that focus. > > Fact is, the kernel debugging tools are, just like drivers, best > maintained with the kernel proper. > > Either DM or AV referred to K's _Practice of Programming_ (p118) in > defense of the avoiding debugger argument. If you have it handy, give that > chapter a read. They devote pretty much their entire chapter on debugging > to the printf school and most of the book lines up with your code quality > philosophy but they still conclude that "a debugger can be of enormous > value, however, and you should certainly include one in your debugging > toolkit.." > > [1] Compare TM's core debuggers to the usefulness of something like IKD > for early work on a new port. > > [2] Note that you're only looking at the antiques that were built well > enough to be around for comparison. > > -- > "Love the dolphins," she advised him. "Write by W.A.S.T.E.." > > -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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/
Re: [RFC] Changes file [was Re: modules directory]
On Sat, 9 Sep 2000, Daniel Phillips wrote: > Simon Huggins wrote: > > On Thu, Sep 07, 2000 at 08:46:56AM +1100, Keith Owens wrote: > > ... and a few more times recent weeks ... > > > > > > > > Why don't you look in linux/Documentation/Changes? That file exist > > > precisely to stop repeated questions like this on the linux kernel > > > developers list. > > > > > > > Because the file just lists versions you need. It doesn't say "since > > version x.y.z you need a newer version". > > > > Why not make it easy on people and have a log something like: > > > > 2.4.0-testX-preY > > Requires modutils-x.y.z otherwise you get error messages like > > "blah blah blah" > > Note you should no longer frobnicate the thingummie or bad > > things will happen. > > 2.3.whatever_it_was > > You need to mount shm on blah. > > > > Now when you tell them to read this file it sticks and *next time* they > > look there too. > > Why? > > Because it's a hell of a lot easier to work out what has changed from > > one version to the next. > > > > It also means that people who ran earlier pre versions of 2.4 but didn't > > upgrade in the mean time for one reason or another can find out what has > > changed between the few versions of this file. > > > > Stuff like the shm stuff and the modutils stuff has generated a fair bit > > of traffic. Having a step by step Changelog style file would help > > people get it right the first time. > > > > Comments? > > I'd like to see a directory in the root of the kernel tree having the > name of the kernel version. Any patch that breaks things writes a one > or two line file into that directory. When it's time to release a > kernel version you do the following: > > cat 2.4.0-testX/* >>Documentation/Changes > rm -rf 2.4.0-testX > > Forgetting to do this rollup is ok, it doesn't hurt anything. > Forgetting to include the change log entry in the patch is ok too - > it's not any worse than the current situation. > > This approach gives us a way of annotating the important effects of > patches that are actually applied. > > I can think of various arguments for not doing this or something like > it, but the only substantive one I can think of is 'no, it would make > it easier to work with the kernel', and I guess this is the argument > that will be applied in this case. Disclaimer: I don't mind, in fact > being an elitist is kind of fun. This is similar to my patch-names patch, which lets you add components to uname too. IIRC, it was rejected because it made things easier. diff -uNr linux-2.2.0-pre6/Makefile linux/Makefile --- linux-2.2.0-pre6/Makefile Wed Jan 6 17:01:15 1999 +++ linux/Makefile Tue Jan 12 17:31:33 1999 @@ -281,7 +281,10 @@ @mv -f .ver $@ include/linux/version.h: ./Makefile - @echo \#define UTS_RELEASE \"$(KERNELRELEASE)\" > .ver + @echo -n \#define UTS_RELEASE \"$(KERNELRELEASE) > .ver + @find -maxdepth 1 -name 'patchdesc.*[^~]' -printf '+%f' | \ + sed -e 's/+patchdesc\./+/g' >> .ver + @echo \" >> .ver @echo \#define LINUX_VERSION_CODE `expr $(VERSION) \\* 65536 + $(PATCHLEVEL) \\* 256 + $(SUBLEVEL)` >> .ver @echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))' >>.ver @mv -f .ver $@ diff -uNr linux-2.2.0-pre6/patchdesc.names linux/patchdesc.names --- linux-2.2.0-pre6/patchdesc.namesWed Dec 31 18:00:00 1969 +++ linux/patchdesc.names Tue Jan 12 17:30:49 1999 @@ -0,0 +1,7 @@ +This patch adds a simple method to identify patched kernels. Patches +that include a file named 'patchdesc.*' in the top level source +directory will cause the kernel to add the file extension to the +version that is reported by uname(1). For instance, this file will +result in the 2.x.x+name being reported. + [EMAIL PROTECTED] Jan 12 1999 -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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/
Re: [RFC] Changes file [was Re: modules directory]
On Sat, 9 Sep 2000, Daniel Phillips wrote: Simon Huggins wrote: On Thu, Sep 07, 2000 at 08:46:56AM +1100, Keith Owens wrote: ... and a few more times recent weeks ... rant Why don't you look in linux/Documentation/Changes? That file exist precisely to stop repeated questions like this on the linux kernel developers list. /rant Because the file just lists versions you need. It doesn't say "since version x.y.z you need a newer version". Why not make it easy on people and have a log something like: 2.4.0-testX-preY Requires modutils-x.y.z otherwise you get error messages like "blah blah blah" Note you should no longer frobnicate the thingummie or bad things will happen. 2.3.whatever_it_was You need to mount shm on blah. Now when you tell them to read this file it sticks and *next time* they look there too. Why? Because it's a hell of a lot easier to work out what has changed from one version to the next. It also means that people who ran earlier pre versions of 2.4 but didn't upgrade in the mean time for one reason or another can find out what has changed between the few versions of this file. Stuff like the shm stuff and the modutils stuff has generated a fair bit of traffic. Having a step by step Changelog style file would help people get it right the first time. Comments? I'd like to see a directory in the root of the kernel tree having the name of the kernel version. Any patch that breaks things writes a one or two line file into that directory. When it's time to release a kernel version you do the following: cat 2.4.0-testX/* Documentation/Changes rm -rf 2.4.0-testX Forgetting to do this rollup is ok, it doesn't hurt anything. Forgetting to include the change log entry in the patch is ok too - it's not any worse than the current situation. This approach gives us a way of annotating the important effects of patches that are actually applied. I can think of various arguments for not doing this or something like it, but the only substantive one I can think of is 'no, it would make it easier to work with the kernel', and I guess this is the argument that will be applied in this case. Disclaimer: I don't mind, in fact being an elitist is kind of fun. This is similar to my patch-names patch, which lets you add components to uname too. IIRC, it was rejected because it made things easier. diff -uNr linux-2.2.0-pre6/Makefile linux/Makefile --- linux-2.2.0-pre6/Makefile Wed Jan 6 17:01:15 1999 +++ linux/Makefile Tue Jan 12 17:31:33 1999 @@ -281,7 +281,10 @@ @mv -f .ver $@ include/linux/version.h: ./Makefile - @echo \#define UTS_RELEASE \"$(KERNELRELEASE)\" .ver + @echo -n \#define UTS_RELEASE \"$(KERNELRELEASE) .ver + @find -maxdepth 1 -name 'patchdesc.*[^~]' -printf '+%f' | \ + sed -e 's/+patchdesc\./+/g' .ver + @echo \" .ver @echo \#define LINUX_VERSION_CODE `expr $(VERSION) \\* 65536 + $(PATCHLEVEL) \\* 256 + $(SUBLEVEL)` .ver @echo '#define KERNEL_VERSION(a,b,c) (((a) 16) + ((b) 8) + (c))' .ver @mv -f .ver $@ diff -uNr linux-2.2.0-pre6/patchdesc.names linux/patchdesc.names --- linux-2.2.0-pre6/patchdesc.namesWed Dec 31 18:00:00 1969 +++ linux/patchdesc.names Tue Jan 12 17:30:49 1999 @@ -0,0 +1,7 @@ +This patch adds a simple method to identify patched kernels. Patches +that include a file named 'patchdesc.*' in the top level source +directory will cause the kernel to add the file extension to the +version that is reported by uname(1). For instance, this file will +result in the 2.x.x+name being reported. + [EMAIL PROTECTED] Jan 12 1999 -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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/
Re: Availability of kdb
[reposted for the benefit of anyone wondering what Linus was replying to] On Sat, 9 Sep 2000, Oliver Xymoron wrote: On Sat, 9 Sep 2000, Linus Torvalds wrote: I use revision control at work. We use CVS on steroids - CVS with a lo tof the extensions available, and with a "mad scientists helper" program called "igor". [...] And with a chip that _includes_ a compiler, we have some debuggers that I don't think exist anywhere else on the planet. Which turns out very useful when the first version of the silicon doesn't actually act the way we thought it would ;) I figured as much on both counts, actually - I was mostly razzing you. So I've seen both. And I still don't think they make for better code. They sometimes make for more expedient release schedules. Which is not the same thing at all. I think the only one who's argued from the release schedule POV is Jeff Merkey. The rest are arguing that debuggers are sometimes useful tools[1]. Tools are tools. They don't make better code. They make better code easier if used properly. Companies are using drills and lathes and table saws and power sanders to produce furniture that doesn't compare to antiques made with hand tools[2]. Does this mean we should make everything by hand? No, it just means we need to be focused on craftsmanship rather than cost. I think the current development culture already has that focus. Fact is, the kernel debugging tools are, just like drivers, best maintained with the kernel proper. Either DM or AV referred to KP's _Practice of Programming_ (p118) in defense of the avoiding debugger argument. If you have it handy, give that chapter a read. They devote pretty much their entire chapter on debugging to the printf school and most of the book lines up with your code quality philosophy but they still conclude that "a debugger can be of enormous value, however, and you should certainly include one in your debugging toolkit.." [1] Compare TM's core debuggers to the usefulness of something like IKD for early work on a new port. [2] Note that you're only looking at the antiques that were built well enough to be around for comparison. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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/
Re: Availability of kdb
On Wed, 6 Sep 2000, Linus Torvalds wrote: > Apparently, if you follow the arguments, not having a kernel debugger > leads to various maladies: > - you crash when something goes wrong, and you fsck and it takes forever >and you get frustrated. > - people have given up on Linux kernel programming because it's too hard >and too time-consuming > - it takes longer to create new features. > > And nobody has explained to me why these are _bad_ things. There are those, but there are others, most of which are so obvious[1] we're not mentioning them, assuming you're familiar with them too. I usually eschew debuggers as well, but I'm beginning to suspect that you've spent so much of your programming life immersed in the kernel that you haven't used a debugger enough to know what sorts of things it's actually good for. Not all the world's a nail, but there are times when the bigger hammer approach is the right one. One of these days you should give revision control a try too. Not to mention bug tracking. :P [1] eg I've found many a compiler bug in 5 minutes of single stepping that days of eyeballing source and adding printfs failed to discover. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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/
Re: [PATCH] 2.2: /proc/config.gz
On Thu, 31 Aug 2000, Alan Cox wrote: > > /lib/modules//.config is a big step up from the current situation > > and I'm grateful. But I do want /proc/config.gz in the kernel. > > So cat it with a magic lead in after the bzImage gzip block into the bzImage. > If you dont even know what file you are running for kernel you have other > problems anyway There are still plenty of situations where this doesn't help. Booted from unsupported USB floppy or CDROM? Netboot? Linload? ROM image? As for the >4k bug, this was a punt on my part. There should be better helper code in procfs to deal with handing out multiple pages and I didn't feel like creating it. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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/
Re: [PATCH] 2.2: /proc/config.gz
On Thu, 31 Aug 2000, Alan Cox wrote: /lib/modules/version/.config is a big step up from the current situation and I'm grateful. But I do want /proc/config.gz in the kernel. So cat it with a magic lead in after the bzImage gzip block into the bzImage. If you dont even know what file you are running for kernel you have other problems anyway There are still plenty of situations where this doesn't help. Booted from unsupported USB floppy or CDROM? Netboot? Linload? ROM image? As for the 4k bug, this was a punt on my part. There should be better helper code in procfs to deal with handing out multiple pages and I didn't feel like creating it. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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/
