Re: Topic for discussion: OS Design
Richard B. Johnson writes: > On Thu, 26 Oct 2000, Albert D. Cahalan wrote: >> Richard B. Johnson writes: >>> o Once installed, a kernel module is every bit as "efficient" >>> as some driver linked into the kernel at build-time. Of course >> >> I doubt this is true on most modern processors. On the Pentium >> and above, large pages are used for the kernel. The PowerPC port > ^^^ > > The page-size is determined by the architecture. The page sizes are determined by the architecture. For common Intel chips: 4 kB, 2 MB, 4 MB. (some restrictions may apply -- Ingo Molnar would know) For ia64, you get about a dozen different sizes ranging from the old 4 kB pages up to something like 256 MB. For the PowerPC you have BAT registers that override page tables. You get 4 for code and 4 for data, so you can map all physical memory for the kernel w/o using page table entries or TLB slots. The SPARC code, if I recall correctly, does not maintain page tables for normal kernel code. If the virtual address is within the direct mapped region, a software TLB loader just adds an offset to get the physical address. So your modules suffer by being unable to take advantage of more efficent virtual-to-physical mapping mechanisms. >> uses BAT registers. Other ports have other hacks to reduce TLB >> misses and/or wasted memory. Also, you waste half a page or more >> for the average module. > > Since kernel memory is allocated in pages, you use whatever you > need. If a module is 4097 bytes in length, you could, in principle, > 'waste' 4095 bytes. So what? it's never paged or otherwise producing > any overhead whatsoever. What, wasted memory is not overhead? Also, consider the cache effects. To keep things simple, assume you have a highly modular kernel and that modules are 2 kB. Also, you have separate 4-way 16 kB L1 caches for code and data. Well, you now have an 8 kB cache for code, along with 8 kB of useless transistors. Of course this is bad, even if you don't have modules that are exactly 2 kB. > These are modules I have written for a project. Since these are object > files, they contain not only code, but also a relocation table. So they > don't require as much memory as the file size shows. However, since > these are all modules, the relocation table is similar in size and > can be considered a constant. > > 6204 Oct 24 10:48 firewire.o8192 - 6204 = 1988 > 11120 Oct 24 10:48 gpib_drvr.o 12288 - 11120 = 1168 > 6692 Oct 24 10:48 ramdisk.o 8192 - 6692 = 1500 > 3886 Oct 24 10:48 rtc_drvr.o4096 - 3886 = 210 > 6776 Oct 25 12:38 vxibus.o 8192 - 6776 = 1416 > Totals >346786282 > > This shows that out of 34,678 bytes we needed, we wasted 6282, ~1.5 > pages. Since there are 5 modules, we waste about 1/3 page per module. > > So I don't, as you say; "... waste 1/2 page or more per module". Somebody else posted their numbers: you waste about 15% of memory. - 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: Topic for discussion: OS Design
Andi Kleen <[EMAIL PROTECTED]>: > On Thu, Oct 26, 2000 at 11:00:03AM -0500, Jesse Pollard wrote: > > Keith Owens <[EMAIL PROTECTED]>: > > > > > > On Thu, 26 Oct 2000 09:17:49 -0400 (EDT), > > > "Richard B. Johnson" <[EMAIL PROTECTED]> wrote: > > [snip] > > > >This shows that out of 34,678 bytes we needed, we wasted 6282, ~1.5 > > > >pages. Since there are 5 modules, we waste about 1/3 page per module. > > > > > > > >So I don't, as you say; "... waste 1/2 page or more per module". > > > > > > Statistics say that the average loss will be 1/2 page per module. Some > > > will waste more, some will waste less, average is 1/2 the unit. > > > > Only if the size of a random module can be between 0 and a full page > > > > Module sizes are skewed data... there is a minimum size for a module > > (somewhere around 1k, I believe - didn't measure it), and if the module > > is going to DO anything then it will be between 1-2K. This skews the data > > sample such that you are only loosing 1/2 of (1 page - minimum) or 1/2 of > > 3K = 1.5K. Hence the 1/3 measured loss will be closer to the correct > > theoretical loss than 1/2. > > You're forgetting that longer modules wrap at the end to a full page, which > makes all values possible again. You appear to be right I thought of them as anomalies, but there are more of them than I believed. I was also thinking of the total number of pages for the modules rather than the total number of modules. The following is from my server (SCSI based, but does have IDE disks too): module size pages loss - -- vfat9116 0 (unused) 2.22559 0.774414 smbfs 26232 0 (unused) 6.4043 0.595703 msdos 5180 0 (unused) 1.26465 0.735352 isofs 17432 0 (unused) 4.25586 0.744141 fat30240 0 [vfat msdos] 7.38281 0.617188 3c509 6004 1 1.46582 0.53418 ide-probe 6244 0 1.52441 0.475586 ide-disk5800 0 1.41602 0.583984 ide-cd 23028 0 5.62207 0.37793 ide-mod44536 0 [ide-probe ide-disk ide-cd] 10.873 0.126953 sb 33876 0 8.27051 0.729492 uart401 5968 0 [sb] 1.45703 0.542969 sound 57336 0 [sb uart401]13.9980.00195312 soundlow 224 0 [sound] 0.05468750.945312 soundcore 2308 5 [sb sound] 0.563477 0.436523 serial 19284 0 (unused) 4.70801 0.291992 lp 5180 0 1.26465 0.735352 parport_pc 5652 1 1.37988 0.620117 parport 7208 1 [lp parport_pc] 1.75977 0.240234 averages: 3.99423 0.532072 So the average size of a module is 3.9 pages and the average size of lost space in a page IS close to .5 (actually a little greater). If the two anomilies (ide-mod and sound) are dropped then the average size of lost space is 0.525288, even close to .5. The only remaining anomily is the soundlow module (size 224). If this one is dropped too then the average size of lost page space is 0.475535. Looking at this, the overall wasted space is a whopping 10.1 pages or 40K. Not bad at all. BTW, all values taken from a Linux 2.2.13.SMP system. - Jesse I Pollard, II Email: [EMAIL PROTECTED] Any opinions expressed are solely my own. - 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: Topic for discussion: OS Design
Keith Owens <[EMAIL PROTECTED]>: > > On Thu, 26 Oct 2000 09:17:49 -0400 (EDT), > "Richard B. Johnson" <[EMAIL PROTECTED]> wrote: [snip] > >This shows that out of 34,678 bytes we needed, we wasted 6282, ~1.5 > >pages. Since there are 5 modules, we waste about 1/3 page per module. > > > >So I don't, as you say; "... waste 1/2 page or more per module". > > Statistics say that the average loss will be 1/2 page per module. Some > will waste more, some will waste less, average is 1/2 the unit. Only if the size of a random module can be between 0 and a full page Module sizes are skewed data... there is a minimum size for a module (somewhere around 1k, I believe - didn't measure it), and if the module is going to DO anything then it will be between 1-2K. This skews the data sample such that you are only loosing 1/2 of (1 page - minimum) or 1/2 of 3K = 1.5K. Hence the 1/3 measured loss will be closer to the correct theoretical loss than 1/2. - Jesse I Pollard, II Email: [EMAIL PROTECTED] Any opinions expressed are solely my own. - 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: Topic for discussion: OS Design
On Thu, 26 Oct 2000 09:17:49 -0400 (EDT), "Richard B. Johnson" <[EMAIL PROTECTED]> wrote: >On Thu, 26 Oct 2000, Albert D. Cahalan wrote: >> I doubt this is true on most modern processors. On the Pentium >> and above, large pages are used for the kernel. The PowerPC port > ^^^ > >The page-size is determined by the architecture. They are 4096 bytes >in the pentium. /usr/include/asm/page.h PAGE_SHIFT = 12, PAGE_SIZE = >1 << PAGE_SHIFT. ADC probably meant "large page tables" as opposed to "large pages". Instead of one page table entry per 4K page, Pentium supports PTEs for contiguous collections of pages, less activity on the page tables generally results in better performance. >This shows that out of 34,678 bytes we needed, we wasted 6282, ~1.5 >pages. Since there are 5 modules, we waste about 1/3 page per module. > >So I don't, as you say; "... waste 1/2 page or more per module". Statistics say that the average loss will be 1/2 page per module. Some will waste more, some will waste less, average is 1/2 the unit. - 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: Topic for discussion: OS Design
On Thu, 26 Oct 2000, Albert D. Cahalan wrote: > Richard B. Johnson writes: > > On Sun, 22 Oct 2000, Dwayne C . Litzenberger wrote: > > > o Once installed, a kernel module is every bit as "efficient" > > as some driver linked into the kernel at build-time. Of course > > I doubt this is true on most modern processors. On the Pentium > and above, large pages are used for the kernel. The PowerPC port ^^^ The page-size is determined by the architecture. They are 4096 bytes in the pentium. /usr/include/asm/page.h PAGE_SHIFT = 12, PAGE_SIZE = 1 << PAGE_SHIFT. It doesn't matter if it's a module (linked during run-time) or a group of procedures (linked during compile time). > uses BAT registers. Other ports have other hacks to reduce TLB > misses and/or wasted memory. Also, you waste half a page or more > for the average module. Since kernel memory is allocated in pages, you use whatever you need. If a module is 4097 bytes in length, you could, in principle, 'waste' 4095 bytes. So what? it's never paged or otherwise producing any overhead whatsoever. These are modules I have written for a project. Since these are object files, they contain not only code, but also a relocation table. So they don't require as much memory as the file size shows. However, since these are all modules, the relocation table is similar in size and can be considered a constant. 6204 Oct 24 10:48 firewire.o8192 - 6204 = 1988 11120 Oct 24 10:48 gpib_drvr.o 12288 - 11120 = 1168 6692 Oct 24 10:48 ramdisk.o 8192 - 6692 = 1500 3886 Oct 24 10:48 rtc_drvr.o4096 - 3886 = 210 6776 Oct 25 12:38 vxibus.o 8192 - 6776 = 1416 Totals 346786282 This shows that out of 34,678 bytes we needed, we wasted 6282, ~1.5 pages. Since there are 5 modules, we waste about 1/3 page per module. So I don't, as you say; "... waste 1/2 page or more per module". Installed modules are part of the kernel. They are not some 'programs' that are executed via some strange indirection. Every module procedure, (open/close/read/write/ioctl/lseek/poll/etc) is called precisely like any "permanent" driver. There is no additional overhead. Cheers, Dick Johnson Penguin : Linux version 2.2.17 on an i686 machine (801.18 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - 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: Topic for discussion: OS Design
Keith Owens [EMAIL PROTECTED]: On Thu, 26 Oct 2000 09:17:49 -0400 (EDT), "Richard B. Johnson" [EMAIL PROTECTED] wrote: [snip] This shows that out of 34,678 bytes we needed, we wasted 6282, ~1.5 pages. Since there are 5 modules, we waste about 1/3 page per module. So I don't, as you say; "... waste 1/2 page or more per module". Statistics say that the average loss will be 1/2 page per module. Some will waste more, some will waste less, average is 1/2 the unit. Only if the size of a random module can be between 0 and a full page Module sizes are skewed data... there is a minimum size for a module (somewhere around 1k, I believe - didn't measure it), and if the module is going to DO anything then it will be between 1-2K. This skews the data sample such that you are only loosing 1/2 of (1 page - minimum) or 1/2 of 3K = 1.5K. Hence the 1/3 measured loss will be closer to the correct theoretical loss than 1/2. - Jesse I Pollard, II Email: [EMAIL PROTECTED] Any opinions expressed are solely my own. - 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: Topic for discussion: OS Design
Andi Kleen [EMAIL PROTECTED]: On Thu, Oct 26, 2000 at 11:00:03AM -0500, Jesse Pollard wrote: Keith Owens [EMAIL PROTECTED]: On Thu, 26 Oct 2000 09:17:49 -0400 (EDT), "Richard B. Johnson" [EMAIL PROTECTED] wrote: [snip] This shows that out of 34,678 bytes we needed, we wasted 6282, ~1.5 pages. Since there are 5 modules, we waste about 1/3 page per module. So I don't, as you say; "... waste 1/2 page or more per module". Statistics say that the average loss will be 1/2 page per module. Some will waste more, some will waste less, average is 1/2 the unit. Only if the size of a random module can be between 0 and a full page Module sizes are skewed data... there is a minimum size for a module (somewhere around 1k, I believe - didn't measure it), and if the module is going to DO anything then it will be between 1-2K. This skews the data sample such that you are only loosing 1/2 of (1 page - minimum) or 1/2 of 3K = 1.5K. Hence the 1/3 measured loss will be closer to the correct theoretical loss than 1/2. You're forgetting that longer modules wrap at the end to a full page, which makes all values possible again. You appear to be right I thought of them as anomalies, but there are more of them than I believed. I was also thinking of the total number of pages for the modules rather than the total number of modules. The following is from my server (SCSI based, but does have IDE disks too): module size pages loss - -- vfat9116 0 (unused) 2.22559 0.774414 smbfs 26232 0 (unused) 6.4043 0.595703 msdos 5180 0 (unused) 1.26465 0.735352 isofs 17432 0 (unused) 4.25586 0.744141 fat30240 0 [vfat msdos] 7.38281 0.617188 3c509 6004 1 1.46582 0.53418 ide-probe 6244 0 1.52441 0.475586 ide-disk5800 0 1.41602 0.583984 ide-cd 23028 0 5.62207 0.37793 ide-mod44536 0 [ide-probe ide-disk ide-cd] 10.873 0.126953 sb 33876 0 8.27051 0.729492 uart401 5968 0 [sb] 1.45703 0.542969 sound 57336 0 [sb uart401]13.9980.00195312 soundlow 224 0 [sound] 0.05468750.945312 soundcore 2308 5 [sb sound] 0.563477 0.436523 serial 19284 0 (unused) 4.70801 0.291992 lp 5180 0 1.26465 0.735352 parport_pc 5652 1 1.37988 0.620117 parport 7208 1 [lp parport_pc] 1.75977 0.240234 averages: 3.99423 0.532072 So the average size of a module is 3.9 pages and the average size of lost space in a page IS close to .5 (actually a little greater). If the two anomilies (ide-mod and sound) are dropped then the average size of lost space is 0.525288, even close to .5. The only remaining anomily is the soundlow module (size 224). If this one is dropped too then the average size of lost page space is 0.475535. Looking at this, the overall wasted space is a whopping 10.1 pages or 40K. Not bad at all. BTW, all values taken from a Linux 2.2.13.SMP system. - Jesse I Pollard, II Email: [EMAIL PROTECTED] Any opinions expressed are solely my own. - 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: Topic for discussion: OS Design
Richard B. Johnson writes: On Thu, 26 Oct 2000, Albert D. Cahalan wrote: Richard B. Johnson writes: o Once installed, a kernel module is every bit as "efficient" as some driver linked into the kernel at build-time. Of course I doubt this is true on most modern processors. On the Pentium and above, large pages are used for the kernel. The PowerPC port ^^^ The page-size is determined by the architecture. The page sizes are determined by the architecture. For common Intel chips: 4 kB, 2 MB, 4 MB. (some restrictions may apply -- Ingo Molnar would know) For ia64, you get about a dozen different sizes ranging from the old 4 kB pages up to something like 256 MB. For the PowerPC you have BAT registers that override page tables. You get 4 for code and 4 for data, so you can map all physical memory for the kernel w/o using page table entries or TLB slots. The SPARC code, if I recall correctly, does not maintain page tables for normal kernel code. If the virtual address is within the direct mapped region, a software TLB loader just adds an offset to get the physical address. So your modules suffer by being unable to take advantage of more efficent virtual-to-physical mapping mechanisms. uses BAT registers. Other ports have other hacks to reduce TLB misses and/or wasted memory. Also, you waste half a page or more for the average module. Since kernel memory is allocated in pages, you use whatever you need. If a module is 4097 bytes in length, you could, in principle, 'waste' 4095 bytes. So what? it's never paged or otherwise producing any overhead whatsoever. What, wasted memory is not overhead? Also, consider the cache effects. To keep things simple, assume you have a highly modular kernel and that modules are 2 kB. Also, you have separate 4-way 16 kB L1 caches for code and data. Well, you now have an 8 kB cache for code, along with 8 kB of useless transistors. Of course this is bad, even if you don't have modules that are exactly 2 kB. These are modules I have written for a project. Since these are object files, they contain not only code, but also a relocation table. So they don't require as much memory as the file size shows. However, since these are all modules, the relocation table is similar in size and can be considered a constant. 6204 Oct 24 10:48 firewire.o8192 - 6204 = 1988 11120 Oct 24 10:48 gpib_drvr.o 12288 - 11120 = 1168 6692 Oct 24 10:48 ramdisk.o 8192 - 6692 = 1500 3886 Oct 24 10:48 rtc_drvr.o4096 - 3886 = 210 6776 Oct 25 12:38 vxibus.o 8192 - 6776 = 1416 Totals 346786282 This shows that out of 34,678 bytes we needed, we wasted 6282, ~1.5 pages. Since there are 5 modules, we waste about 1/3 page per module. So I don't, as you say; "... waste 1/2 page or more per module". Somebody else posted their numbers: you waste about 15% of memory. - 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: Topic for discussion: OS Design
Richard B. Johnson writes: > On Sun, 22 Oct 2000, Dwayne C . Litzenberger wrote: > o Once installed, a kernel module is every bit as "efficient" > as some driver linked into the kernel at build-time. Of course I doubt this is true on most modern processors. On the Pentium and above, large pages are used for the kernel. The PowerPC port uses BAT registers. Other ports have other hacks to reduce TLB misses and/or wasted memory. Also, you waste half a page or more for the average module. - 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: Topic for discussion: OS Design
Richard B. Johnson writes: On Sun, 22 Oct 2000, Dwayne C . Litzenberger wrote: o Once installed, a kernel module is every bit as "efficient" as some driver linked into the kernel at build-time. Of course I doubt this is true on most modern processors. On the Pentium and above, large pages are used for the kernel. The PowerPC port uses BAT registers. Other ports have other hacks to reduce TLB misses and/or wasted memory. Also, you waste half a page or more for the average module. - 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: Topic for discussion: OS Design
On Mon, 23 Oct 2000, Hacksaw wrote: > > Another linux caveat. Scads of undocumented and virtually undiscoverable > > behaviours :-) > > Undiscoverable? You have the source code, what more do you want? > Start documenting! TOO LATE ;) I documented all that stuff quite a while ago, see Documentation/sysctl/ ... OTOH, these documents could use some updates for 2.4 ... any volunteers? ;) regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - 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: Topic for discussion: OS Design
On Mon, 23 Oct 2000, Dennis wrote: > At 07:19 PM 10/23/2000, Andi Kleen wrote: > >On Mon, Oct 23, 2000 at 06:43:28PM -0400, Dennis wrote: > > > - FreeBSD will display kernel print messages with syslogd not running, and > > > linux will not. > > > >Linux will also when the console log level is set high enough (which it > >is by default, just it is usually too low after you killed klogd). > >Unqualified printks have level 4, so you need a level > that. > >Some distributions also unfortunately set bogus defaults or redirect > >the messages to specific virtual consoles. > > Another linux caveat. Scads of undocumented and virtually > undiscoverable behaviours :-) Don't blame others for the fact that you haven't read Documentation/sysctl/kernel.txt ... Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - 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: Topic for discussion: OS Design + GPL
On Mon, 23 Oct 2000, Andre Hedrick wrote: > Subject: Re: Topic for discussion: OS Design + GPL > > ftp://ftp.etinc.com/pub/linux/linux22_hdlc.tgz > > Could explain to me why ET Inc is modifying GPL drivers and then > republishing the binaries as modules only? > > Not that it is my sub-system, but I am not sure that my friend Don knows > of this issue. If Don does not care then, good day. > > ls hdlc/usr/hdlc/dev/modules/2.2.14 > . eepro100.o etbwmgr.o tulip.o > .. eepro100orig.o ethdlc.otuliporig.o I very much care. Neither the eepro100.c nor the tulip.c driver have been released under any license but the Gnu GPL. Any distribution of those drivers must only be done under the terms of the GPL. That includes providing a copy of the GPL text and making a specific offer of source code as required by the GPL. If you have offered driver object files without offering the source code,, you have terminated your right of redistribution of the code per paragraph 4 of the GPL. That means you have no right to distribute the drivers, even if the violation is corrected. In general I will reinstate redistribution rights if - the license violation is acknowledged - you provide a specific plan to prevent future violations - you notify all existing recipients of the license violation, including their right to receive the source code. This reinstatement of rights is not automatic, especially with evidence of continued, willful violations. Donald Becker [EMAIL PROTECTED] Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 - 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: Topic for discussion: OS Design
David Woodhouse wrote: > > [EMAIL PROTECTED] said: > > The pc speaker is fine for playing one note at a time - it is > > extremely shitty hardware if you want to play samples. > > It's actually quite reasonable for sound effects. Stuff like beeps and > boings to announce talk requests, new mail, etc. But yes, playing mp3s on > it does suck somewhat :) > > > A dirt cheap used soundcard or even a resistor network connected to the > > parallel port is a good DAC-device compared to the pc speaker. > > Note that the latter is also supported by the PCSP driver, and has to play > the same evil timer tricks. When I finally get round to shifting the system Interesting! > timer onto the RTC so the PCSP driver can have the 8253 all to itself, > the PCSP driver will be a lot nicer. It doesn't impact the system > performance that much at all. Maybe I overestimated the overhead of the pc-speaker sound driver. Still, the quality is dubious due to the hardware. Some case designers fit the cheapest possible speaker / piezo-electric device in order to minimize cost. (It is only used for system beeps so why use something expensive. Who cares if there is scratching on a beep due to somthing located too near the membrane...) And don't even try asking a pc-case salesman about the quality of the built-in speaker. Helge Hafting - 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: Topic for discussion: OS Design
On Mon, Oct 23, 2000 at 12:51:16PM -0700, [EMAIL PROTECTED] wrote: > On Sun, 22 Oct 2000, Dwayne C . Litzenberger wrote: > > This user also wants a > > smooth GUI, a mouse pointer that doesn't flinch under load, > > Try andrea archangeli's VM patches. When I use those patches X gets much > smoother and xmms (with nice -5) never skips. 2.2 VM sucks, film at 11. What the realtion of these patches with Rick's new VM architecture for 2.4.x ? Will 2.4.x give similar performance you mentioned with andrea's patches ? - Gabor - 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: Topic for discussion: OS Design
On Mon, Oct 23, 2000 at 12:51:16PM -0700, [EMAIL PROTECTED] wrote: On Sun, 22 Oct 2000, Dwayne C . Litzenberger wrote: This user also wants a smooth GUI, a mouse pointer that doesn't flinch under load, Try andrea archangeli's VM patches. When I use those patches X gets much smoother and xmms (with nice -5) never skips. 2.2 VM sucks, film at 11. What the realtion of these patches with Rick's new VM architecture for 2.4.x ? Will 2.4.x give similar performance you mentioned with andrea's patches ? - Gabor - 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: Topic for discussion: OS Design
David Woodhouse wrote: [EMAIL PROTECTED] said: The pc speaker is fine for playing one note at a time - it is extremely shitty hardware if you want to play samples. It's actually quite reasonable for sound effects. Stuff like beeps and boings to announce talk requests, new mail, etc. But yes, playing mp3s on it does suck somewhat :) A dirt cheap used soundcard or even a resistor network connected to the parallel port is a good DAC-device compared to the pc speaker. Note that the latter is also supported by the PCSP driver, and has to play the same evil timer tricks. When I finally get round to shifting the system Interesting! timer onto the RTC so the PCSP driver can have the 8253 all to itself, the PCSP driver will be a lot nicer. It doesn't impact the system performance that much at all. Maybe I overestimated the overhead of the pc-speaker sound driver. Still, the quality is dubious due to the hardware. Some case designers fit the cheapest possible speaker / piezo-electric device in order to minimize cost. (It is only used for system beeps so why use something expensive. Who cares if there is scratching on a beep due to somthing located too near the membrane...) And don't even try asking a pc-case salesman about the quality of the built-in speaker. Helge Hafting - 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: Topic for discussion: OS Design + GPL
On Mon, 23 Oct 2000, Andre Hedrick wrote: Subject: Re: Topic for discussion: OS Design + GPL ftp://ftp.etinc.com/pub/linux/linux22_hdlc.tgz Could explain to me why ET Inc is modifying GPL drivers and then republishing the binaries as modules only? Not that it is my sub-system, but I am not sure that my friend Don knows of this issue. If Don does not care then, good day. ls hdlc/usr/hdlc/dev/modules/2.2.14 . eepro100.o etbwmgr.o tulip.o .. eepro100orig.o ethdlc.otuliporig.o I very much care. Neither the eepro100.c nor the tulip.c driver have been released under any license but the Gnu GPL. Any distribution of those drivers must only be done under the terms of the GPL. That includes providing a copy of the GPL text and making a specific offer of source code as required by the GPL. If you have offered driver object files without offering the source code,, you have terminated your right of redistribution of the code per paragraph 4 of the GPL. That means you have no right to distribute the drivers, even if the violation is corrected. In general I will reinstate redistribution rights if - the license violation is acknowledged - you provide a specific plan to prevent future violations - you notify all existing recipients of the license violation, including their right to receive the source code. This reinstatement of rights is not automatic, especially with evidence of continued, willful violations. Donald Becker [EMAIL PROTECTED] Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 - 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: Topic for discussion: OS Design
On Mon, 23 Oct 2000, Dennis wrote: At 07:19 PM 10/23/2000, Andi Kleen wrote: On Mon, Oct 23, 2000 at 06:43:28PM -0400, Dennis wrote: - FreeBSD will display kernel print messages with syslogd not running, and linux will not. Linux will also when the console log level is set high enough (which it is by default, just it is usually too low after you killed klogd). Unqualified printks have level 4, so you need a level that. Some distributions also unfortunately set bogus defaults or redirect the messages to specific virtual consoles. Another linux caveat. Scads of undocumented and virtually undiscoverable behaviours :-) Don't blame others for the fact that you haven't read Documentation/sysctl/kernel.txt ... Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - 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: Topic for discussion: OS Design
On Mon, 23 Oct 2000, Hacksaw wrote: Another linux caveat. Scads of undocumented and virtually undiscoverable behaviours :-) Undiscoverable? You have the source code, what more do you want? Start documenting! TOO LATE ;) I documented all that stuff quite a while ago, see Documentation/sysctl/ ... OTOH, these documents could use some updates for 2.4 ... any volunteers? ;) regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - 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: Topic for discussion: OS Design
On Mon, Oct 23, 2000 at 07:43:24PM -0400, Dennis wrote: > At 07:19 PM 10/23/2000, Andi Kleen wrote: > >On Mon, Oct 23, 2000 at 06:43:28PM -0400, Dennis wrote: > > > - FreeBSD will display kernel print messages with syslogd not running, and > > > linux will not. > > > >Linux will also when the console log level is set high enough (which it > >is by default, just it is usually too low after you killed klogd). > >Unqualified printks have level 4, so you need a level > that. > >Some distributions also unfortunately set bogus defaults or redirect > >the messages to specific virtual consoles. > > > Another linux caveat. Scads of undocumented and virtually undiscoverable > behaviours :-) It is not undocumented. Try reading the klogd manpage. -Andi - 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: Topic for discussion: OS Design
On Mon, 23 Oct 2000, Hacksaw wrote: > > Another linux caveat. Scads of undocumented and virtually undiscoverable > > behaviours :-) > > Undiscoverable? You have the source code, what more do you want? Start > documenting! Oh no then they would have to publish their findings, and that is only available in binary format or $500.00 USD and threats for a lawyer. Regardless that the original code was GPL I am BATING someone to answer why they are selling GPL code and making legal gestures if you pay for the GPL code and share the GPL code. Someone must have a harder time than me reading the rules. Cheers, Andre Hedrick The Linux ATA/IDE guy - 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: Topic for discussion: OS Design
> Another linux caveat. Scads of undocumented and virtually undiscoverable > behaviours :-) Undiscoverable? You have the source code, what more do you want? Start documenting! - 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: Topic for discussion: OS Design + GPL
ftp://ftp.etinc.com/pub/linux/linux22_hdlc.tgz Hi Dennis, Could explain to me why ET Inc is modifying GPL drivers and then republishing the binaries as modules only? Not that it is my sub-system, but I am not sure that my friend Don knows of this issue. If Don does not care then, good day. ls hdlc/usr/hdlc/dev/modules/2.2.14 . eepro100.o etbwmgr.o tulip.o .. eepro100orig.o ethdlc.otuliporig.o Cheers, Andre Hedrick The Linux ATA/IDE guy - 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: Topic for discussion: OS Design
On Mon, Oct 23, 2000 at 06:43:28PM -0400, Dennis wrote: > - FreeBSD will display kernel print messages with syslogd not running, and > linux will not. Linux will also when the console log level is set high enough (which it is by default, just it is usually too low after you killed klogd). Unqualified printks have level 4, so you need a level > that. Some distributions also unfortunately set bogus defaults or redirect the messages to specific virtual consoles. > - FreeBSD doesnt (seem) to have the buffering problem that linux does, in > that exceptionally long messages (like decoding a Frame Relay LMI frame > with 1000 elements) work just fine. You cannot print more than the kernel log buffers size without scheduling inbetween to let klogd eat some of the buffer. I don't see a way how FreeBSD could do that better, except if they found a way to store infinite data in a finite buffer (or alternatively not store your LMI frame completely in the syslog, which would be also as bad) It is possible that their default buffer is bigger though. Linux's default is 16K, which is a bit on the low side for many things. You can increase it of course with a simple recompile by changing the define in kernel/printk.c Admittedly one problem in Linux with big printks is that it kills your interrupt latency completely. There are lower overhead alternatives though. > - FreeBSD will display messages immediately without a newline > - FreeBSD messages 1) can be redirected and 2) are printed without a timestamp. Both just like in Linux. The timestamps come from syslogd/klogd, not the kernel. -Andi - 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: Topic for discussion: OS Design
At 04:35 PM 10/23/2000, you wrote: >On Mon, 23 Oct 2000, Dennis wrote: > > > This is typical of the "linux mentality". Why do other OSs have solutions > > that work, yet linux's method requires special coding? If it "has to be > > done that way", why do other OS's have solutions that dont do it that way? > > the size of the buffer is an annoyance but not a serious problem however. > > > >I'm not sure that Linux requires any special coding. > > > printing directly to the console (as BSD does) is useful when debugging a > > panic, as you can trace right to the panic point. Also certain levels of > >BSD does not write directly to the console. Its console is a direct >clone of Linux. I'm not sure which came first, but when you have a single >screen-card there are not too many ways to get the character and attribute >into screen memory. Linux allows the console to be redirected to a serial >port. BSD does not last time I checked. - FreeBSD will display kernel print messages with syslogd not running, and linux will not. - FreeBSD doesnt (seem) to have the buffering problem that linux does, in that exceptionally long messages (like decoding a Frame Relay LMI frame with 1000 elements) work just fine. - FreeBSD will display messages immediately without a newline - FreeBSD messages 1) can be redirected and 2) are printed without a timestamp. which implies that you are wrong about just about everything. >What? The API has remained consistent since 0.99. It's only internal >kernel stuff that has changed. If you wrote code that worked on 0.99, >it will still compile and work on 2.2.17. We are talking about the kernel. What are you talking about? The external view is meaningless. the device driver interface changed substantially in 2.0. The module interface changed, as it is changing again in 2.4. The PCI interface has changed and is changing again. >The only reason to get the 'latest' version is to take advantage >of increased functionality. This, by definition, means that something >has changed. That's what you upgrade for. The word "unstable" is a >misnomer. Usually my customers want to upgrade because of some security fix or bug fix, not to get new features. > > My point is that there is no "stable kernel series". 2.2.0 wasnt stable, > > and neither was 2.2.3. Virtually all of the ethernet drivers still lock up > > under heavy load in 2.2.17...and now with 2.4 there are more countless > > adventures ahead > >Which Ethernet drivers are you having trouble with? The ones that had >lockup problems (incidentally hardware related), now have reset code >that runs off a watch-dog. The eepro100 driver is an ongoing project, still with lockup problems. the tulip has issues as well. > > an example of "poor planning" is that skput and skpush will panic the > > kernel if there is no room (this can happen with multiple encapsulations) > > The proper behaviour would be to return a NULL pointer indicating failure, > > and then to drop the frame and issue a warning. > >The proper response to any resource not being available (in networking) >is to drop the packet on the floor, smash it into little pieces, and >don't tell anybody about it. > >The packet will be sent again. But, if you can't transmit a packet, >therefore freeing a buffer, what do you do? > >What you do is realilize that the failure to transmit was likely >caused by a disconnected wire. In the drivers I use, I simply pretend >that every packet got transmitted okay. This usually involves a >one or two-line modification to the driver. > >This has nothing to do with poor planning. It just has to do with >a design decision that I didn't agree with. Somebody decided that >network data was precious and therefore the machine should kill itself >if necessary to get the data through. > >I didn't agree with this so I changed a few lines of code. You can't >kill any of my machines by flooding them and they never lock up. >Further, they run at 85 to 90 percent of the network physical layer >bandwidth. My main machine is our domain name-server, it gets between >2000 and 5000 hits per second. If it crashed, our whole LAN goes >down. It doesn't. It runs Linux-2.2.17. Right. So your answer is that linux is OK if you modify all of the broken stuff yourself. Im glad we are in agreement on that, if nothing else. DB - 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: Topic for discussion: OS Design
On Mon, 23 Oct 2000, Dennis wrote: > This is typical of the "linux mentality". Why do other OSs have solutions > that work, yet linux's method requires special coding? If it "has to be > done that way", why do other OS's have solutions that dont do it that way? > the size of the buffer is an annoyance but not a serious problem however. > I'm not sure that Linux requires any special coding. > printing directly to the console (as BSD does) is useful when debugging a > panic, as you can trace right to the panic point. Also certain levels of BSD does not write directly to the console. Its console is a direct clone of Linux. I'm not sure which came first, but when you have a single screen-card there are not too many ways to get the character and attribute into screen memory. Linux allows the console to be redirected to a serial port. BSD does not last time I checked. > > > >Bugs that were found when changing the design of various kernel > >procedures, have been back-ported to the stable kernel series. > > I never use development kernels, what Im talking about is each major > release is like starting from version 1.0. By the time it stabilizes, the > next major puts it back to square one. What? The API has remained consistent since 0.99. It's only internal kernel stuff that has changed. If you wrote code that worked on 0.99, it will still compile and work on 2.2.17. You could not have written code for 0.99 that used mmap() and some other stuff because it had not been developed yet. However, all the "Unix stuff" like read/write/open/close/ioctl/lseek, etc., and their buffered versions like fopen() from the 'C' runtime library, have had the same API since day one. Linux was developed, from the start, to have a POSIX compatible API. Most of that API comes from the 'C' runtime library, the exact same API used by BSD and all the other OS's to which the GNU library has been ported. The only reason to get the 'latest' version is to take advantage of increased functionality. This, by definition, means that something has changed. That's what you upgrade for. The word "unstable" is a misnomer. > My point is that there is no "stable kernel series". 2.2.0 wasnt stable, > and neither was 2.2.3. Virtually all of the ethernet drivers still lock up > under heavy load in 2.2.17...and now with 2.4 there are more countless > adventures ahead Which Ethernet drivers are you having trouble with? The ones that had lockup problems (incidentally hardware related), now have reset code that runs off a watch-dog. > an example of "poor planning" is that skput and skpush will panic the > kernel if there is no room (this can happen with multiple encapsulations) > The proper behaviour would be to return a NULL pointer indicating failure, > and then to drop the frame and issue a warning. The proper response to any resource not being available (in networking) is to drop the packet on the floor, smash it into little pieces, and don't tell anybody about it. The packet will be sent again. But, if you can't transmit a packet, therefore freeing a buffer, what do you do? What you do is realilize that the failure to transmit was likely caused by a disconnected wire. In the drivers I use, I simply pretend that every packet got transmitted okay. This usually involves a one or two-line modification to the driver. This has nothing to do with poor planning. It just has to do with a design decision that I didn't agree with. Somebody decided that network data was precious and therefore the machine should kill itself if necessary to get the data through. I didn't agree with this so I changed a few lines of code. You can't kill any of my machines by flooding them and they never lock up. Further, they run at 85 to 90 percent of the network physical layer bandwidth. My main machine is our domain name-server, it gets between 2000 and 5000 hits per second. If it crashed, our whole LAN goes down. It doesn't. It runs Linux-2.2.17. Script started on Mon Oct 23 16:12:02 2000 # rlogin boneserver Password: Last login: Mon Oct 23 11:28:29 from chaos.analogic.com Linux 2.2.17. [3g[25;9HH[25;17HH[25;25HH[25;33HH[25;41HH[25;49HH[25;57HH[25;65HH[25;73HH <)0 # uptime 4:12pm up 24 days, 22:21, 11 users, load average: 0.81, 0.62, 0.00 # exit logout rlogin: connection closed. # exit exit Script done on Mon Oct 23 16:12:27 2000 Those 11 users are all network servers including samba for M$ connectivity. One of the major advantages of Linux is that if you don't like a design decision that was made, you are free to do it over the way you think is right. Sometimes you can convince others that your way is better. Sometimes not. If so, your patch makes it into the main-line kernel, if not, you patch your own future kernels so you get to retain your improvements. FYI, if AC did not exist, another would appear to fill the vacuum. Don't bitch. Make some improvements and send patches. Cheers, Dick Johnson Penguin :
Re: Topic for discussion: OS Design
On Sun, 22 Oct 2000, Dwayne C . Litzenberger wrote: > This user also wants a > smooth GUI, a mouse pointer that doesn't flinch under load, Try andrea archangeli's VM patches. When I use those patches X gets much smoother and xmms (with nice -5) never skips. 2.2 VM sucks, film at 11. > and a small > enough > system that he won't have to be swapping all the time (not entirely > kernel's > fault). Huh? RAM is cheap. If 128MB of PC133 isn't enough for you, then it isn't the kernel's fault, its your bloated apps. - 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: Topic for discussion: OS Design
This is typical of the "linux mentality". Why do other OSs have solutions
that work, yet linux's method requires special coding? If it "has to be
done that way", why do other OS's have solutions that dont do it that way?
the size of the buffer is an annoyance but not a serious problem however.
printing directly to the console (as BSD does) is useful when debugging a
panic, as you can trace right to the panic point. Also certain levels of
output will trash the screen, requiring a reset (switching to another
virtual console and then switching back, unfortunately flushing the buffer
will do it). Im not sure if it has been fixed, but also writing without a
newline used to cause garbage to be spewed to the screen, which meant a
screen line had to be used for each message.
At 02:08 PM 10/23/2000, Richard B. Johnson wrote:
>On Mon, 23 Oct 2000, Dennis wrote:
>
> > >
> > >o What used to take a month to get working in SunOS, will
> > >take a few hours on Linux. Linux has continually improved the
> > >resources available to the modules. In the beginning there was
> > >a kernel memory allocator. Now we have common resource allocation
> > >code for I/O addresses like PCI, common interrupt handlers, common
> > >sleep and wake-up routines, etc. Basically, the best ideas of
> > >all the driver contributors have been adapted into a kernel-driver
> > >interface so that every compliant module gets to share the best
> > >code available.
> >
> > As long as your modules are trivial, you are correct. I agree that writing
> > a basic module is fairly easy, and debugging is easy (although if they
> > fixed the printk interface it would be easier), but.
> >
>
>Some of the stuff we do is hardly trivial. Could you explan what you
>have found wrong with printk()? I have never had any problem with it.
>If you are referring to the limited-size buffering of the output, this
>is not something that requires a "fix". It is deliberate so that even
>and out-of-memory situation can be displayed. Printk()'s buffer is
>allocated once and is fixed-length. If you use printk for what it
>is supposed to be used for, you will never have any problems.
>
>There are other ways than printk() to write output to the current
>task's output. printk() is most useful where there isn't a well-
>defined 'current'.
>
>static void print_string(char *str)
>{
>struct tty_struct *tty = current->tty;
>(*tty->driver.write)(tty, 0, str, strlen(str));
>(*tty->driver.write)(tty, 0, "\r\n", 2);
>}
>
> > "compliance" is difficult without good documentation,and unfortunately
> most
> > of the docs for the linux kernel are in Alan Cox's head (and the like).
> > Virtually all books are out of date by the time they hit the shelves (the
> > linux "device driver" book had many errors and omissions and proved more
> > detrimental than useful). Most of the how-tos are out of date. This,
> > understandable, is what you get for free.
> >
> > Also, the definition of "compliant" keeps changing. the difference
> between
> > a real commercial OS and linux is that linux is a moving target.
> >
>
>Look, if you are doing product development, it's counter-productive to
>use a __development__ kernel. You can spend too much time keeping up
>with the changes. Instead, just like you should never change your tools
>during a product design cycle, you should not change the effective
>kernel you use.
>
>The "stable" kernel, i.e., 2.2.5 -> 2.2.17 has been kept up-to-date
>as far as bug fixes are concerned. My drivers work fine in this
>series.
>
>At some later date, when the current development kernel becomes
>the "stable" kernel, I will make whatever changes are necessary to
>my (at last count) 12 drivers so they work in the new kernel.
>This is something that will happen during the normal product lifetime,
>not before the products are being shipped.
>
>
> > While they might brag about LINUX being "fast moving", it is also the main
> > reason that it is continuously unstable and the hopes of true stability
> > any time soon is questionable. Until they stop hacking core elements and
> > redesigning interfaces on the fly there will be no change. Just lots of
> new
> > features that almost work as long as you use them in a particular way.
> >
> > theres a lot to be said for doing something right the first time and
> > sticking with it even if it isnt perfect. Unfortunately many of the
> > original linux designs were so poorly thought out that they need to be
> > completely redesigned.
> >
>
>Not true. You can't have reviewed or understand any of the kernel code if
>you believe this. All major elements are modular. When somebody comes
>up with better memory management, it's encorporated, better scheduling,
>it's encorporated, etc. This is what development kernels are for.
>
>Bugs that were found when changing the design of various kernel
>procedures, have been back-ported to the stable kernel series.
I never use development kernels, what Im talking about is
Re: Topic for discussion: OS Design
On Sun, 22 Oct 2000, Dwayne C . Litzenberger wrote: > Then I start hearing about khttpd, something that (ideally) > should go in user space, > hardware drivers are rejected (PCSP is my example, but what if > some other device is as kludgy as the pcsp? Will it be rejected > too?) PCSP isn't in the kernel because the DRIVER was kludgy. Khttpd is in because it isn't... If you really want a driver for the PC speaker in the kernel, why don't you show your commitment by writing one which isn't kludgy ? > Patches for features I want are a nightmare. You may want to consider fixing them. If you're capable of making statements regarding the achitecture of the whole system, surely you'll be able to do such a simple task as cleaning up device drivers? > My complaint is from a user's point of view. This particular > user wants software-suspend, pcsp, reiserfs, USB, and agpgart. > This user also wants a smooth GUI, a mouse pointer that doesn't > flinch under load, and a small enough system that he won't have > to be swapping all the time (not entirely kernel's fault). All > these things are reasonable. Send patches. regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - 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: Topic for discussion: OS Design
On Mon, 23 Oct 2000, Dennis wrote:
> >
> >o What used to take a month to get working in SunOS, will
> >take a few hours on Linux. Linux has continually improved the
> >resources available to the modules. In the beginning there was
> >a kernel memory allocator. Now we have common resource allocation
> >code for I/O addresses like PCI, common interrupt handlers, common
> >sleep and wake-up routines, etc. Basically, the best ideas of
> >all the driver contributors have been adapted into a kernel-driver
> >interface so that every compliant module gets to share the best
> >code available.
>
> As long as your modules are trivial, you are correct. I agree that writing
> a basic module is fairly easy, and debugging is easy (although if they
> fixed the printk interface it would be easier), but.
>
Some of the stuff we do is hardly trivial. Could you explan what you
have found wrong with printk()? I have never had any problem with it.
If you are referring to the limited-size buffering of the output, this
is not something that requires a "fix". It is deliberate so that even
and out-of-memory situation can be displayed. Printk()'s buffer is
allocated once and is fixed-length. If you use printk for what it
is supposed to be used for, you will never have any problems.
There are other ways than printk() to write output to the current
task's output. printk() is most useful where there isn't a well-
defined 'current'.
static void print_string(char *str)
{
struct tty_struct *tty = current->tty;
(*tty->driver.write)(tty, 0, str, strlen(str));
(*tty->driver.write)(tty, 0, "\r\n", 2);
}
> "compliance" is difficult without good documentation,and unfortunately most
> of the docs for the linux kernel are in Alan Cox's head (and the like).
> Virtually all books are out of date by the time they hit the shelves (the
> linux "device driver" book had many errors and omissions and proved more
> detrimental than useful). Most of the how-tos are out of date. This,
> understandable, is what you get for free.
>
> Also, the definition of "compliant" keeps changing. the difference between
> a real commercial OS and linux is that linux is a moving target.
>
Look, if you are doing product development, it's counter-productive to
use a __development__ kernel. You can spend too much time keeping up
with the changes. Instead, just like you should never change your tools
during a product design cycle, you should not change the effective
kernel you use.
The "stable" kernel, i.e., 2.2.5 -> 2.2.17 has been kept up-to-date
as far as bug fixes are concerned. My drivers work fine in this
series.
At some later date, when the current development kernel becomes
the "stable" kernel, I will make whatever changes are necessary to
my (at last count) 12 drivers so they work in the new kernel.
This is something that will happen during the normal product lifetime,
not before the products are being shipped.
> While they might brag about LINUX being "fast moving", it is also the main
> reason that it is continuously unstable and the hopes of true stability
> any time soon is questionable. Until they stop hacking core elements and
> redesigning interfaces on the fly there will be no change. Just lots of new
> features that almost work as long as you use them in a particular way.
>
> theres a lot to be said for doing something right the first time and
> sticking with it even if it isnt perfect. Unfortunately many of the
> original linux designs were so poorly thought out that they need to be
> completely redesigned.
>
Not true. You can't have reviewed or understand any of the kernel code if
you believe this. All major elements are modular. When somebody comes
up with better memory management, it's encorporated, better scheduling,
it's encorporated, etc. This is what development kernels are for.
Bugs that were found when changing the design of various kernel
procedures, have been back-ported to the stable kernel series.
Cheers,
Dick Johnson
Penguin : Linux version 2.2.17 on an i686 machine (801.18 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
-
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: Topic for discussion: OS Design
> >Then you get more incorrect documentation and discover that the >kernel interface has changed. You repeat this whole episode until >you finally get to 'talk' to the hardware that your driver is >supposed to control. This is only the beginning. > >With Linux, you just write the code. You put in a few debugging >statements here and there. You make sure you don't do something >dumb like write to some address you don't own, you compile it, >then you insert it using `insmod`. If it doesn't work, you use >`rmmod` to remove it. If the documentation is wrong or hasn't >been updated, you just *look* at the source-code, observing how >some other working module did it. > >o What used to take a month to get working in SunOS, will >take a few hours on Linux. Linux has continually improved the >resources available to the modules. In the beginning there was >a kernel memory allocator. Now we have common resource allocation >code for I/O addresses like PCI, common interrupt handlers, common >sleep and wake-up routines, etc. Basically, the best ideas of >all the driver contributors have been adapted into a kernel-driver >interface so that every compliant module gets to share the best >code available. As long as your modules are trivial, you are correct. I agree that writing a basic module is fairly easy, and debugging is easy (although if they fixed the printk interface it would be easier), but. "compliance" is difficult without good documentation,and unfortunately most of the docs for the linux kernel are in Alan Cox's head (and the like). Virtually all books are out of date by the time they hit the shelves (the linux "device driver" book had many errors and omissions and proved more detrimental than useful). Most of the how-tos are out of date. This, understandable, is what you get for free. Also, the definition of "compliant" keeps changing. the difference between a real commercial OS and linux is that linux is a moving target. While they might brag about LINUX being "fast moving", it is also the main reason that it is continuously unstable and the hopes of true stability any time soon is questionable. Until they stop hacking core elements and redesigning interfaces on the fly there will be no change. Just lots of new features that almost work as long as you use them in a particular way. theres a lot to be said for doing something right the first time and sticking with it even if it isnt perfect. Unfortunately many of the original linux designs were so poorly thought out that they need to be completely redesigned. DB - 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: Topic for discussion: OS Design
"Dwayne C . Litzenberger" wrote: > > First of all, I'd like to say that I'm not writing this to piss anyone off. > It's not a flame, a troll, or a personal attack on anyone. I my writing will > aid in the improvement of Linux. Please read this with as much neutrality as > you can summon. I think everyone who first writes here and hasn´t read the archives asks this... This is a technical mailinglist ... If you have technical comments which are welcome, you are welcome otherwise go to play. > > Although I am a programmer, I am not yet a kernel hacker, so some of my claims > may be false. Feel free to correct me. Yeah 16 year old calling himself a programmer ... Ever heard about programming theory OS design theory?? Ok alan (-> Alan Cox ...) says that there is a HUGE difference between theory and practise... > "Practice what you preach; don't preach what you practice." and beating phrases > A few years ago, there was an intense debate around the question of > cooperative vs. preemptive multitasking operating system design. Today, > however, cooperative multitasking is a thing of the past, and it is virtually > undisputed that the preemptive multitasking design is highly superior to the > cooperative one. Yes, and pre-emptive _is_ better because one cannot rely on the user being sensitive ... especially script kiddies like you ... > What's the difference? Well, operating systems employing cooperative > multitasking are no longer in the mainstream. There is no longer a need to > pointlessly defend the status quo. > s.a. > Linux's loadable modules design is insufficient. I have several reasons for > making this claim: Is it?? its only designed to make it possible to link parts of the kernel during runtime ... makes debugging frivers easier ... > 1. Many things are inaccessible to the modules: There are relatively few > kernel modifications that can be compiled without patching the pristine > sources. Ehhm as modules run in kernel nearly everything is accessible for em ... as long as they do it the right way. When things arent accessible for modules it is because its well thought of... > 2. The modules API is unstable. Some people say this is because of the > exceedingly rapid development cycle of Linux. I beg to differ. I believe it > is because there is no real planned structure in the API -- just passing > highly volatile internal data structures around. Nope the API is developed with the kernel ... And its really easy to design a device driver ... Try it ... look at the joystick driver... for a start ... > 3. Modules can very easily crash the whole kernel. This is because each > module does not get to run in its own protected memory space, as it would in a > well-designed microkernel. Wepp- run em all in seperate memspaces and do context switches all the time which is one of the most time consuming tasks on a cpu ... (saving and restoring a whole register set ...) > 5. Linus tends to blame patches for inadequacies in the kernel. The PC > speaker driver is a perfect example: No driver should have to do something > "dirty" in order to function, because the operating system should provide > clean ways to do this. > > It would seem that a microkernel design would fix most of these problems. Two > very elegant operating systems, namely the Amiga's exec.library and QNX's > Neutrino (I'm sure you can name others), used microkernels, and they were both > *very* efficient. However, there are some drawbacks to microkernels that have > been raised (and I don't have the expertise to argue about them), but I think > there are enough intelligent people here that we can come up with a new OS > design that takes the best from both worlds. This may require a new mailing > list. Amiga design is *old* ... Windows is relatively old QNX is hacked to fit onto a floppy and it is a RTOS for you who doesnt know: Real Time Operating System, Real time means that the OS has to respond to requests in a certain time which is well defined ( could also be 1 second, but the OS has to guarantee that it will handle any request in the worst case in 1 second (latency) which is highly unrealistic (1 sec) There are linux low-latency patches which make linux more responsible (probably what you call "speed") Linux does fit on a floppy too (there are enough tars you can download... > > So, my question is this: What are some of Linux's design problems, and what > fundamental changes could be made for a long-run benefit? > > -- > Dwayne C. Litzenberger - [EMAIL PROTECTED] > > - Please always Cc to me when replying to me on the lists. > - Please have the courtesy to respond to any requests or questions I may have. Wow, ure the king here aren´t you?? > - See the mail headers for GPG/advertising/homepage information. ^ I dont care about such crap, and I´m sure everybody else here doesnt... > >
Re: Topic for discussion: OS Design
[EMAIL PROTECTED] said: > The pc speaker is fine for playing one note at a time - it is > extremely shitty hardware if you want to play samples. It's actually quite reasonable for sound effects. Stuff like beeps and boings to announce talk requests, new mail, etc. But yes, playing mp3s on it does suck somewhat :) > A dirt cheap used soundcard or even a resistor network connected to the > parallel port is a good DAC-device compared to the pc speaker. Note that the latter is also supported by the PCSP driver, and has to play the same evil timer tricks. When I finally get round to shifting the system timer onto the RTC so the PCSP driver can have the 8253 all to itself, the PCSP driver will be a lot nicer. It doesn't impact the system performance that much at all. -- dwmw2 - 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: Topic for discussion: OS Design
On Sun, 22 Oct 2000, Dwayne C . Litzenberger wrote: > > Linux's loadable modules design is insufficient. I have several reasons for > making this claim: > > 1. Many things are inaccessible to the modules: There are relatively few > kernel modifications that can be compiled without patching the pristine > sources. > > 2. The modules API is unstable. Some people say this is because of the > exceedingly rapid development cycle of Linux. I beg to differ. I believe it > is because there is no real planned structure in the API -- just passing > highly volatile internal data structures around. > > 3. Modules can very easily crash the whole kernel. This is because each > module does not get to run in its own protected memory space, as it would in a > well-designed microkernel. > >From time-to-time, the linux-kernel list gets inquiries that may generally be considered to be coming from a troll. However, some of these inquiries seem to be somewhat valid and seem to have been generated by some well advertised misinformation. In particular, often certain buzz-words are used to "prove", "demonstrate", or simply "show" that one particular implementation detail is better than another. I'm going to address just one detail of this misinformation, "kernel modules". o Once installed, a kernel module is every bit as "efficient" as some driver linked into the kernel at build-time. Of course the code necessary to install and remove a kernel module may not very efficient because it was designed to be straight-forward and reliable, not necessarily efficient. After all, a module is typically installed in the kernel once, early in the boot process. Nothing, absolutely nothing is, as you say, inaccessible to the module unless it is inaccessible to other parts of the kernel (like a DECnet address in Redmond). o A kernel module is a piece of kernel code. It executes as part of the kernel and, therefore, can do anything it wants to do including destroying anything. A kernel module is not a piece of user code that gets a chance to run with some advantage within the kernel. If a kernel module was designed for this purpose, the kernel module code is being misused. A "microkernel" provides no protection for bad modules. This buzz-word is irrelevant. o Because of the excellent design of the kernel module interface, practically any amateur 'C' coder can write a kernel module. If that coder has access to the root account, the module can be installed. The result often proves that it takes more than the knowledge of a 'C' compiler to produce something of value that executes within kernel space. The fact that it is possible to write code that destroys the kernel is irrelevant. If the proper kernel interface code is used, like copy_to_user(), copy_from_user(), etc., within the module, it is impossible for a user to hurt the kernel from the user's API. FYI "highly volatile" make no sense. In the context of programming an object is either volatile or not. It cannot be "highly volatile". o The ability to install and remove modules from a running kernel is one of the most significant accomplishments of Linux. Anybody who has written drivers for other operating systems can substantiate the awful development cycle. Typically, you write the driver according to a template provided by the vendor. You finally get it to compile. Then you run some obscure vendor-supplied program that 'links' it with the operating system. Then you reboot. You do this over-and-over again until you have discovered all the errors in the vendor's documentation. Eventually, you get to test your driver code. It doesn't work. Then you get more incorrect documentation and discover that the kernel interface has changed. You repeat this whole episode until you finally get to 'talk' to the hardware that your driver is supposed to control. This is only the beginning. With Linux, you just write the code. You put in a few debugging statements here and there. You make sure you don't do something dumb like write to some address you don't own, you compile it, then you insert it using `insmod`. If it doesn't work, you use `rmmod` to remove it. If the documentation is wrong or hasn't been updated, you just *look* at the source-code, observing how some other working module did it. o What used to take a month to get working in SunOS, will take a few hours on Linux. Linux has continually improved the resources available to the modules. In the beginning there was a kernel memory allocator. Now we have common resource allocation code for I/O addresses like PCI, common interrupt handlers, common sleep and wake-up routines, etc. Basically, the best ideas of all the driver contributors have been adapted into a kernel-driver interface so that every compliant module gets to share the best code available. Cheers, Dick Johnson Penguin : Linux version 2.2.17 on an i686 machine (801.18 BogoMips). "Memory is like gasoline. You use it up when you
Re: Topic for discussion: OS Design
"Dwayne C . Litzenberger" <[EMAIL PROTECTED]> said: [...] > Then, I heard of Linux, and installed it. What a difference! Much > faster, and sooo stable! I loved it. It was still clunky, and slow > (compare a P120MHz to an Amiga 7.14Mhz -- should be 16x as fast, but it's > not), Comparing different architectures and implementations by raw clock speed is absolutely meaningless. You might try standard CPU/machine benchmarks (like the Byte benchmarks, f.ex.). Also note that the OS and language implementation comes into the picture. It would probably be most fair to compare AmigaOS with DOS (no separate user/system space). Plus they are of approximately the same vintage. > but I still thought it was because of the PC hardware. Executable > code sizes bugged me a bit (usually 10-100x larger than Amiga). Check sizes of object files (*.o) not full executables. Check memory- resident sizes (size(1)), not file sizes (which can include huge debugging information). > Then I got the QNX demodisk. It was amazing what they could fit on that > disk! Yes. But this is far from a general-purpose system, and it was clearly heavyly hacked to size. I've build linux-on-a-diskette systems myself... and given a smallish VGA-only browser (can be done! but what is the point?) Linux could do the same. [...] > So, then, I was asking myself: WHY is Linux so slow and clunky in > comparison? I knew that GCC was not the most efficient compiler in the > world, but it wasn't that bad. Where is Linux (the kernel) slow and clunky? Or are you blaming the bloat of Netscape on Linux? You know, this kind of sweeping comments without a shred of fact or at least a closer look for the origins of what you are complaining about to back them up just make you look bad. Soon you'll end up in everybody's killfile, or at least with a mental note "read for possible amusement, ignore otherwise". > Then I start hearing about khttpd, something that (ideally) should go in > user space, hardware drivers are rejected (PCSP is my example, but what > if some other device is as kludgy as the pcsp? Will it be rejected > too?), and software-suspend mysteriously disappears from Alan's -ac > patches. X (a hardware driver) is in user space, and so is svgalib. It > all looks very messy. The atyfb still doesn't work for my Rage Pro > (2.2.x, anyway. Never tried 2.[34]). Patches for features I want are a > nightmare. Then stay well away from experimental patches, and unsupported hardware. And do as you were told: Go read about OS design, Unix in particular. Get a hold on X design. Then check out the PC design, and compare it with anything built 10 years before. Keep the barfbag handy. > My complaint is from a user's point of view. This particular user wants > software-suspend, pcsp, reiserfs, USB, and agpgart. This user also wants > a smooth GUI, a mouse pointer that doesn't flinch under load, and a small > enough system that he won't have to be swapping all the time (not > entirely kernel's fault). All these things are reasonable. Then help out getting there. Complaining gets you into killfiles, nowhere else. Or pick up a oh-so-wonderful-other-OS that gives you all that and leave us alone. [...] > -- > Dwayne C. Litzenberger - [EMAIL PROTECTED] > > - Please always Cc to me when replying to me on the lists. > - Please have the courtesy to respond to any requests or questions I may ha= > ve. You do realize that all this is extremely rude, don't you? > - See the mail headers for GPG/advertising/homepage information. -- Dr. Horst H. von Brand mailto:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - 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: Topic for discussion: OS Design
"Dwayne C . Litzenberger" <[EMAIL PROTECTED]> said: [...] > So what we really need to do is get some custom "RAM blitter" into our > hardware to do the memory copies needed for fast context switching and > message passing. Nope. The problem is that RAM is slow. No way around that. -- Dr. Horst H. von Brand mailto:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - 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: Topic for discussion: OS Design
"Dwayne C . Litzenberger" wrote: > > First of all, I'd like to say that I'm not writing this to piss anyone off. > It's not a flame, a troll, or a personal attack on anyone. I my writing will > aid in the improvement of Linux. Please read this with as much neutrality as > you can summon. And please search the kernel list message archives before posting stuff like this. People here are smart, and the reason they don't discuss your ideas are because they were all discussed some years ago, everybody agree on the conclusions, and don't want to discuss the same things again just to please a newbie. Search the archives - the answers is there. > > Although I am a programmer, I am not yet a kernel hacker, so some of my claims > may be false. Good that you acknowledge this. Kernel programming is different from other programming, so usual software design rules does not apply. > "Practice what you preach; don't preach what you practice." > > A few years ago, there was an intense debate around the question of > cooperative vs. preemptive multitasking operating system design. Today, > however, cooperative multitasking is a thing of the past, and it is virtually > undisputed that the preemptive multitasking design is highly superior to the > cooperative one. Yeah, cooperative is a joke, and always was. The only reason for ever using it is that cooperating was perceived as "simple to implement", and some os designers had the mistaken belief that you could expect application programmers to be "diciplined enough" to yield the cpu often enough. They couldn't be more wrong. There are too many bad application programmers around. Just expect more from your machine than cooperative os'es can give you. > What's the difference? Well, operating systems employing cooperative > multitasking are no longer in the mainstream. There is no longer a need to > pointlessly defend the status quo. > Now to something completely different: > Linux's loadable modules design is insufficient. I have several reasons for > making this claim: > > 1. Many things are inaccessible to the modules: There are relatively few > kernel modifications that can be compiled without patching the pristine > sources. Write patches then. One thing you really should know before posting here: Nobody works for you here, so you *can't* request _anything_. It is a great way of pissing people off. People here code up whatever _they_ want, not what you want. There is no service. The correct question is this: "Would it be a good idea for *me* to fix this, and if so, can someone help me getting started?" > 2. The modules API is unstable. Some people say this is because of the > exceedingly rapid development cycle of Linux. I beg to differ. I believe it > is because there is no real planned structure in the API -- just passing > highly volatile internal data structures around. This is by design. There is no modules API. If you need a stable API, code modules for a single kernel revision. You may have some mistaken idea about what modules is in linux. Not necessarily what modules is in other os'es. You are expected to recompile all modules with each new kernel revision, just like compiling the kernel itself. A module is merely a part of the kernel itself which doesn't have to be there all the time. > 3. Modules can very easily crash the whole kernel. This is because each > module does not get to run in its own protected memory space, as it would in a > well-designed microkernel. > Yes, modules can easily bring the kernel down. Error in a module can crash the kernel just like an error in the kernel can crash the kernel. This because a module is a part of the kernel, there is no difference or protection. The _only_ difference is that any module can be loaded a long time after the kernel is booted, and most modules can be unloaded as well. So modules can be used to save memory. And they simplify distributions as you make a bootable kernel smaller than the size of a floppy, and still provide support for absolutely any hardware by loading modules from other floppies or the cdrom. And developers can unload a module, fix the code, recompile it, and load the new module without booting. And that's it. Modules are _not_ an attempt to be microkernel-ish. They are not supposed to be in a protected space, as they aren't different from the kernel. They are the kernel, just like the memory-resident code. If you want something in a protected memory space - write a program. If you need this to be a driver, write a minimal device driver and a program, and let the program handle everything that don't need to be in the driver. > 4. The kernel HTTPD is just masking a slow networking design. Yes, I agree > that high-level protocols should be eventually incorporated into a > standardized interface in an operating system. However, there would be no > need for a kernel-based httpd if the kernel was efficient enough. This leads > into my
Re: Topic for discussion: OS Design
Marty Fouts writes: > I have had the good fortune of working with one architecture (PA-RISC) which > gets the separation of addressability and accessability 'right' enough to be > able to partition efficiently and use ordinary procedure calls (with some > magic at server boundaries) rather than IPCs. There are others, but PA-RISC > is the one I am aware of. Like S/390 secondary address space and cross-address-space services? --Malcolm -- Malcolm Beattie <[EMAIL PROTECTED]> Unix Systems Programmer Oxford University Computing Services - 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: Topic for discussion: OS Design
On Sun, Oct 22, 2000 at 09:56:52PM -0600, Dwayne C . Litzenberger wrote: > Too bad nobody on this list works at an electronics design company... ;-P Doesn't Transmeta count as an electronics design company? ;) -- Adam Sampson [EMAIL PROTECTED] - 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: Topic for discussion: OS Design
On Sun, Oct 22, 2000 at 04:29:19PM -0600, Dwayne C . Litzenberger wrote: > 5. Linus tends to blame patches for inadequacies in the kernel. The PC > speaker driver is a perfect example: No driver should have to do something > "dirty" in order to function, because the operating system should provide > clean ways to do this. > It would seem that a microkernel design would fix most of these problems. Well, try to implement the PC speaker driver in a microkernel. It'll have to be even uglier (and much more when at that) than what the driver is now. And, yes, this all has been discussed many many times around with little benefit. -- Vojtech Pavlik SuSE Labs - 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: Topic for discussion: OS Design
[EMAIL PROTECTED] (Dwayne C . Litzenberger) writes: You contradict yourself: [...] > 3. Modules can very easily crash the whole kernel. This is because > each module does not get to run in its own protected memory space, as > it would i= n a well-designed microkernel. [...] > very elegant operating systems, namely the Amiga's exec.library and > QNX's Neutrino (I'm sure you can name others), used microkernels, and > they were b= oth *very* efficient. However, there are some drawbacks > to microkernels that h= ave [...] The AmigaOS (as I remember it from my past days) was fast because it had no memory protection between user and kernel space at all. So you could simply pass around message pointers without copying any data from kernel to user space. Yeah. Cool. Fast. Crashed like hell all the time you made one false move. Please, go and play with the other CS undergrads on Hurd. Or climb a tree. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED] Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED] D-91054 Buckenhof Fax.: 09131 / 50654-20 - 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: Topic for discussion: OS Design
:59 PM To: Peter Waltenberg Cc: [EMAIL PROTECTED] Subject: Re: Topic for discussion: OS Design On Mon, Oct 23, 2000 at 08:53:26AM +1000, Peter Waltenberg wrote: > Use the GNU Hurd, it won't run on most hardware you'd like to use, and it's > probably slower than Linux, but it's a microkernel. I'll ignore that. > I've worked with microkernels, IMHO, they suck :). Good idea, but fundamentally > flawed. The same things that make them more robust (and they are more robust) > also kill performance. Could you elaborate? AFAIK, both Neutrino and exec.library are microkernels, and they by no means lack performance. Even Windows is a microkernel (sort of), and it doesn't lack in performance that much. -- Dwayne C. Litzenberger - [EMAIL PROTECTED] - Please always Cc to me when replying to me on the lists. - Please have the courtesy to respond to any requests or questions I may have. - See the mail headers for GPG/advertising/homepage information. - 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: Topic for discussion: OS Design
:59 PM To: Peter Waltenberg Cc: [EMAIL PROTECTED] Subject: Re: Topic for discussion: OS Design On Mon, Oct 23, 2000 at 08:53:26AM +1000, Peter Waltenberg wrote: Use the GNU Hurd, it won't run on most hardware you'd like to use, and it's probably slower than Linux, but it's a microkernel. I'll ignore that. I've worked with microkernels, IMHO, they suck :). Good idea, but fundamentally flawed. The same things that make them more robust (and they are more robust) also kill performance. Could you elaborate? AFAIK, both Neutrino and exec.library are microkernels, and they by no means lack performance. Even Windows is a microkernel (sort of), and it doesn't lack in performance that much. -- Dwayne C. Litzenberger - [EMAIL PROTECTED] - Please always Cc to me when replying to me on the lists. - Please have the courtesy to respond to any requests or questions I may have. - See the mail headers for GPG/advertising/homepage information. - 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: Topic for discussion: OS Design
[EMAIL PROTECTED] (Dwayne C . Litzenberger) writes: You contradict yourself: [...] 3. Modules can very easily crash the whole kernel. This is because each module does not get to run in its own protected memory space, as it would i= n a well-designed microkernel. [...] very elegant operating systems, namely the Amiga's exec.library and QNX's Neutrino (I'm sure you can name others), used microkernels, and they were b= oth *very* efficient. However, there are some drawbacks to microkernels that h= ave [...] The AmigaOS (as I remember it from my past days) was fast because it had no memory protection between user and kernel space at all. So you could simply pass around message pointers without copying any data from kernel to user space. Yeah. Cool. Fast. Crashed like hell all the time you made one false move. Please, go and play with the other CS undergrads on Hurd. Or climb a tree. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED] Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED] D-91054 Buckenhof Fax.: 09131 / 50654-20 - 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: Topic for discussion: OS Design
On Sun, Oct 22, 2000 at 04:29:19PM -0600, Dwayne C . Litzenberger wrote: 5. Linus tends to blame patches for inadequacies in the kernel. The PC speaker driver is a perfect example: No driver should have to do something "dirty" in order to function, because the operating system should provide clean ways to do this. It would seem that a microkernel design would fix most of these problems. Well, try to implement the PC speaker driver in a microkernel. It'll have to be even uglier (and much more when at that) than what the driver is now. And, yes, this all has been discussed many many times around with little benefit. -- Vojtech Pavlik SuSE Labs - 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: Topic for discussion: OS Design
On Sun, Oct 22, 2000 at 09:56:52PM -0600, Dwayne C . Litzenberger wrote: Too bad nobody on this list works at an electronics design company... ;-P Doesn't Transmeta count as an electronics design company? ;) -- Adam Sampson [EMAIL PROTECTED] - 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: Topic for discussion: OS Design
Marty Fouts writes: I have had the good fortune of working with one architecture (PA-RISC) which gets the separation of addressability and accessability 'right' enough to be able to partition efficiently and use ordinary procedure calls (with some magic at server boundaries) rather than IPCs. There are others, but PA-RISC is the one I am aware of. Like S/390 secondary address space and cross-address-space services? --Malcolm -- Malcolm Beattie [EMAIL PROTECTED] Unix Systems Programmer Oxford University Computing Services - 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: Topic for discussion: OS Design
"Dwayne C . Litzenberger" wrote: First of all, I'd like to say that I'm not writing this to piss anyone off. It's not a flame, a troll, or a personal attack on anyone. I my writing will aid in the improvement of Linux. Please read this with as much neutrality as you can summon. And please search the kernel list message archives before posting stuff like this. People here are smart, and the reason they don't discuss your ideas are because they were all discussed some years ago, everybody agree on the conclusions, and don't want to discuss the same things again just to please a newbie. Search the archives - the answers is there. Although I am a programmer, I am not yet a kernel hacker, so some of my claims may be false. Good that you acknowledge this. Kernel programming is different from other programming, so usual software design rules does not apply. "Practice what you preach; don't preach what you practice." A few years ago, there was an intense debate around the question of cooperative vs. preemptive multitasking operating system design. Today, however, cooperative multitasking is a thing of the past, and it is virtually undisputed that the preemptive multitasking design is highly superior to the cooperative one. Yeah, cooperative is a joke, and always was. The only reason for ever using it is that cooperating was perceived as "simple to implement", and some os designers had the mistaken belief that you could expect application programmers to be "diciplined enough" to yield the cpu often enough. They couldn't be more wrong. There are too many bad application programmers around. Just expect more from your machine than cooperative os'es can give you. What's the difference? Well, operating systems employing cooperative multitasking are no longer in the mainstream. There is no longer a need to pointlessly defend the status quo. Now to something completely different: Linux's loadable modules design is insufficient. I have several reasons for making this claim: 1. Many things are inaccessible to the modules: There are relatively few kernel modifications that can be compiled without patching the pristine sources. Write patches then. One thing you really should know before posting here: Nobody works for you here, so you *can't* request _anything_. It is a great way of pissing people off. People here code up whatever _they_ want, not what you want. There is no service. The correct question is this: "Would it be a good idea for *me* to fix this, and if so, can someone help me getting started?" 2. The modules API is unstable. Some people say this is because of the exceedingly rapid development cycle of Linux. I beg to differ. I believe it is because there is no real planned structure in the API -- just passing highly volatile internal data structures around. This is by design. There is no modules API. If you need a stable API, code modules for a single kernel revision. You may have some mistaken idea about what modules is in linux. Not necessarily what modules is in other os'es. You are expected to recompile all modules with each new kernel revision, just like compiling the kernel itself. A module is merely a part of the kernel itself which doesn't have to be there all the time. 3. Modules can very easily crash the whole kernel. This is because each module does not get to run in its own protected memory space, as it would in a well-designed microkernel. Yes, modules can easily bring the kernel down. Error in a module can crash the kernel just like an error in the kernel can crash the kernel. This because a module is a part of the kernel, there is no difference or protection. The _only_ difference is that any module can be loaded a long time after the kernel is booted, and most modules can be unloaded as well. So modules can be used to save memory. And they simplify distributions as you make a bootable kernel smaller than the size of a floppy, and still provide support for absolutely any hardware by loading modules from other floppies or the cdrom. And developers can unload a module, fix the code, recompile it, and load the new module without booting. And that's it. Modules are _not_ an attempt to be microkernel-ish. They are not supposed to be in a protected space, as they aren't different from the kernel. They are the kernel, just like the memory-resident code. If you want something in a protected memory space - write a program. If you need this to be a driver, write a minimal device driver and a program, and let the program handle everything that don't need to be in the driver. 4. The kernel HTTPD is just masking a slow networking design. Yes, I agree that high-level protocols should be eventually incorporated into a standardized interface in an operating system. However, there would be no need for a kernel-based httpd if the kernel was efficient enough. This leads into my next point: 5. Linus tends to blame
Re: Topic for discussion: OS Design
"Dwayne C . Litzenberger" [EMAIL PROTECTED] said: [...] So what we really need to do is get some custom "RAM blitter" into our hardware to do the memory copies needed for fast context switching and message passing. Nope. The problem is that RAM is slow. No way around that. -- Dr. Horst H. von Brand mailto:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - 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: Topic for discussion: OS Design
"Dwayne C . Litzenberger" [EMAIL PROTECTED] said: [...] Then, I heard of Linux, and installed it. What a difference! Much faster, and sooo stable! I loved it. It was still clunky, and slow (compare a P120MHz to an Amiga 7.14Mhz -- should be 16x as fast, but it's not), Comparing different architectures and implementations by raw clock speed is absolutely meaningless. You might try standard CPU/machine benchmarks (like the Byte benchmarks, f.ex.). Also note that the OS and language implementation comes into the picture. It would probably be most fair to compare AmigaOS with DOS (no separate user/system space). Plus they are of approximately the same vintage. but I still thought it was because of the PC hardware. Executable code sizes bugged me a bit (usually 10-100x larger than Amiga). Check sizes of object files (*.o) not full executables. Check memory- resident sizes (size(1)), not file sizes (which can include huge debugging information). Then I got the QNX demodisk. It was amazing what they could fit on that disk! Yes. But this is far from a general-purpose system, and it was clearly heavyly hacked to size. I've build linux-on-a-diskette systems myself... and given a smallish VGA-only browser (can be done! but what is the point?) Linux could do the same. [...] So, then, I was asking myself: WHY is Linux so slow and clunky in comparison? I knew that GCC was not the most efficient compiler in the world, but it wasn't that bad. Where is Linux (the kernel) slow and clunky? Or are you blaming the bloat of Netscape on Linux? You know, this kind of sweeping comments without a shred of fact or at least a closer look for the origins of what you are complaining about to back them up just make you look bad. Soon you'll end up in everybody's killfile, or at least with a mental note "read for possible amusement, ignore otherwise". Then I start hearing about khttpd, something that (ideally) should go in user space, hardware drivers are rejected (PCSP is my example, but what if some other device is as kludgy as the pcsp? Will it be rejected too?), and software-suspend mysteriously disappears from Alan's -ac patches. X (a hardware driver) is in user space, and so is svgalib. It all looks very messy. The atyfb still doesn't work for my Rage Pro (2.2.x, anyway. Never tried 2.[34]). Patches for features I want are a nightmare. Then stay well away from experimental patches, and unsupported hardware. And do as you were told: Go read about OS design, Unix in particular. Get a hold on X design. Then check out the PC design, and compare it with anything built 10 years before. Keep the barfbag handy. My complaint is from a user's point of view. This particular user wants software-suspend, pcsp, reiserfs, USB, and agpgart. This user also wants a smooth GUI, a mouse pointer that doesn't flinch under load, and a small enough system that he won't have to be swapping all the time (not entirely kernel's fault). All these things are reasonable. Then help out getting there. Complaining gets you into killfiles, nowhere else. Or pick up a oh-so-wonderful-other-OS that gives you all that and leave us alone. [...] -- Dwayne C. Litzenberger - [EMAIL PROTECTED] - Please always Cc to me when replying to me on the lists. - Please have the courtesy to respond to any requests or questions I may ha= ve. You do realize that all this is extremely rude, don't you? - See the mail headers for GPG/advertising/homepage information. -- Dr. Horst H. von Brand mailto:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - 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: Topic for discussion: OS Design
On Sun, 22 Oct 2000, Dwayne C . Litzenberger wrote: Linux's loadable modules design is insufficient. I have several reasons for making this claim: 1. Many things are inaccessible to the modules: There are relatively few kernel modifications that can be compiled without patching the pristine sources. 2. The modules API is unstable. Some people say this is because of the exceedingly rapid development cycle of Linux. I beg to differ. I believe it is because there is no real planned structure in the API -- just passing highly volatile internal data structures around. 3. Modules can very easily crash the whole kernel. This is because each module does not get to run in its own protected memory space, as it would in a well-designed microkernel. From time-to-time, the linux-kernel list gets inquiries that may generally be considered to be coming from a troll. However, some of these inquiries seem to be somewhat valid and seem to have been generated by some well advertised misinformation. In particular, often certain buzz-words are used to "prove", "demonstrate", or simply "show" that one particular implementation detail is better than another. I'm going to address just one detail of this misinformation, "kernel modules". o Once installed, a kernel module is every bit as "efficient" as some driver linked into the kernel at build-time. Of course the code necessary to install and remove a kernel module may not very efficient because it was designed to be straight-forward and reliable, not necessarily efficient. After all, a module is typically installed in the kernel once, early in the boot process. Nothing, absolutely nothing is, as you say, inaccessible to the module unless it is inaccessible to other parts of the kernel (like a DECnet address in Redmond). o A kernel module is a piece of kernel code. It executes as part of the kernel and, therefore, can do anything it wants to do including destroying anything. A kernel module is not a piece of user code that gets a chance to run with some advantage within the kernel. If a kernel module was designed for this purpose, the kernel module code is being misused. A "microkernel" provides no protection for bad modules. This buzz-word is irrelevant. o Because of the excellent design of the kernel module interface, practically any amateur 'C' coder can write a kernel module. If that coder has access to the root account, the module can be installed. The result often proves that it takes more than the knowledge of a 'C' compiler to produce something of value that executes within kernel space. The fact that it is possible to write code that destroys the kernel is irrelevant. If the proper kernel interface code is used, like copy_to_user(), copy_from_user(), etc., within the module, it is impossible for a user to hurt the kernel from the user's API. FYI "highly volatile" make no sense. In the context of programming an object is either volatile or not. It cannot be "highly volatile". o The ability to install and remove modules from a running kernel is one of the most significant accomplishments of Linux. Anybody who has written drivers for other operating systems can substantiate the awful development cycle. Typically, you write the driver according to a template provided by the vendor. You finally get it to compile. Then you run some obscure vendor-supplied program that 'links' it with the operating system. Then you reboot. You do this over-and-over again until you have discovered all the errors in the vendor's documentation. Eventually, you get to test your driver code. It doesn't work. Then you get more incorrect documentation and discover that the kernel interface has changed. You repeat this whole episode until you finally get to 'talk' to the hardware that your driver is supposed to control. This is only the beginning. With Linux, you just write the code. You put in a few debugging statements here and there. You make sure you don't do something dumb like write to some address you don't own, you compile it, then you insert it using `insmod`. If it doesn't work, you use `rmmod` to remove it. If the documentation is wrong or hasn't been updated, you just *look* at the source-code, observing how some other working module did it. o What used to take a month to get working in SunOS, will take a few hours on Linux. Linux has continually improved the resources available to the modules. In the beginning there was a kernel memory allocator. Now we have common resource allocation code for I/O addresses like PCI, common interrupt handlers, common sleep and wake-up routines, etc. Basically, the best ideas of all the driver contributors have been adapted into a kernel-driver interface so that every compliant module gets to share the best code available. Cheers, Dick Johnson Penguin : Linux version 2.2.17 on an i686 machine (801.18 BogoMips). "Memory is like gasoline. You use it up when you are running. Of
Re: Topic for discussion: OS Design
[EMAIL PROTECTED] said: The pc speaker is fine for playing one note at a time - it is extremely shitty hardware if you want to play samples. It's actually quite reasonable for sound effects. Stuff like beeps and boings to announce talk requests, new mail, etc. But yes, playing mp3s on it does suck somewhat :) A dirt cheap used soundcard or even a resistor network connected to the parallel port is a good DAC-device compared to the pc speaker. Note that the latter is also supported by the PCSP driver, and has to play the same evil timer tricks. When I finally get round to shifting the system timer onto the RTC so the PCSP driver can have the 8253 all to itself, the PCSP driver will be a lot nicer. It doesn't impact the system performance that much at all. -- dwmw2 - 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: Topic for discussion: OS Design
"Dwayne C . Litzenberger" wrote: First of all, I'd like to say that I'm not writing this to piss anyone off. It's not a flame, a troll, or a personal attack on anyone. I my writing will aid in the improvement of Linux. Please read this with as much neutrality as you can summon. I think everyone who first writes here and hasn´t read the archives asks this... This is a technical mailinglist ... If you have technical comments which are welcome, you are welcome otherwise go to play. Although I am a programmer, I am not yet a kernel hacker, so some of my claims may be false. Feel free to correct me. Yeah 16 year old calling himself a programmer ... Ever heard about programming theory OS design theory?? Ok alan (- Alan Cox ...) says that there is a HUGE difference between theory and practise... "Practice what you preach; don't preach what you practice." and beating phrases A few years ago, there was an intense debate around the question of cooperative vs. preemptive multitasking operating system design. Today, however, cooperative multitasking is a thing of the past, and it is virtually undisputed that the preemptive multitasking design is highly superior to the cooperative one. Yes, and pre-emptive _is_ better because one cannot rely on the user being sensitive ... especially script kiddies like you ... What's the difference? Well, operating systems employing cooperative multitasking are no longer in the mainstream. There is no longer a need to pointlessly defend the status quo. s.a. Linux's loadable modules design is insufficient. I have several reasons for making this claim: Is it?? its only designed to make it possible to link parts of the kernel during runtime ... makes debugging frivers easier ... 1. Many things are inaccessible to the modules: There are relatively few kernel modifications that can be compiled without patching the pristine sources. Ehhm as modules run in kernel nearly everything is accessible for em ... as long as they do it the right way. When things arent accessible for modules it is because its well thought of... 2. The modules API is unstable. Some people say this is because of the exceedingly rapid development cycle of Linux. I beg to differ. I believe it is because there is no real planned structure in the API -- just passing highly volatile internal data structures around. Nope the API is developed with the kernel ... And its really easy to design a device driver ... Try it ... look at the joystick driver... for a start ... 3. Modules can very easily crash the whole kernel. This is because each module does not get to run in its own protected memory space, as it would in a well-designed microkernel. Wepp- run em all in seperate memspaces and do context switches all the time which is one of the most time consuming tasks on a cpu ... (saving and restoring a whole register set ...) 5. Linus tends to blame patches for inadequacies in the kernel. The PC speaker driver is a perfect example: No driver should have to do something "dirty" in order to function, because the operating system should provide clean ways to do this. It would seem that a microkernel design would fix most of these problems. Two very elegant operating systems, namely the Amiga's exec.library and QNX's Neutrino (I'm sure you can name others), used microkernels, and they were both *very* efficient. However, there are some drawbacks to microkernels that have been raised (and I don't have the expertise to argue about them), but I think there are enough intelligent people here that we can come up with a new OS design that takes the best from both worlds. This may require a new mailing list. Amiga design is *old* ... Windows is relatively old QNX is hacked to fit onto a floppy and it is a RTOS for you who doesnt know: Real Time Operating System, Real time means that the OS has to respond to requests in a certain time which is well defined ( could also be 1 second, but the OS has to guarantee that it will handle any request in the worst case in 1 second (latency) which is highly unrealistic (1 sec) There are linux low-latency patches which make linux more responsible (probably what you call "speed") Linux does fit on a floppy too (there are enough tars you can download... So, my question is this: What are some of Linux's design problems, and what fundamental changes could be made for a long-run benefit? -- Dwayne C. Litzenberger - [EMAIL PROTECTED] - Please always Cc to me when replying to me on the lists. - Please have the courtesy to respond to any requests or questions I may have. Wow, ure the king here aren´t you?? - See the mail headers for GPG/advertising/homepage information. ^ I dont care about such crap, and I´m sure everybody else here doesnt... - To unsubscribe from this list: send
Re: Topic for discussion: OS Design
Then you get more incorrect documentation and discover that the kernel interface has changed. You repeat this whole episode until you finally get to 'talk' to the hardware that your driver is supposed to control. This is only the beginning. With Linux, you just write the code. You put in a few debugging statements here and there. You make sure you don't do something dumb like write to some address you don't own, you compile it, then you insert it using `insmod`. If it doesn't work, you use `rmmod` to remove it. If the documentation is wrong or hasn't been updated, you just *look* at the source-code, observing how some other working module did it. o What used to take a month to get working in SunOS, will take a few hours on Linux. Linux has continually improved the resources available to the modules. In the beginning there was a kernel memory allocator. Now we have common resource allocation code for I/O addresses like PCI, common interrupt handlers, common sleep and wake-up routines, etc. Basically, the best ideas of all the driver contributors have been adapted into a kernel-driver interface so that every compliant module gets to share the best code available. As long as your modules are trivial, you are correct. I agree that writing a basic module is fairly easy, and debugging is easy (although if they fixed the printk interface it would be easier), but. "compliance" is difficult without good documentation,and unfortunately most of the docs for the linux kernel are in Alan Cox's head (and the like). Virtually all books are out of date by the time they hit the shelves (the linux "device driver" book had many errors and omissions and proved more detrimental than useful). Most of the how-tos are out of date. This, understandable, is what you get for free. Also, the definition of "compliant" keeps changing. the difference between a real commercial OS and linux is that linux is a moving target. While they might brag about LINUX being "fast moving", it is also the main reason that it is continuously unstable and the hopes of true stability any time soon is questionable. Until they stop hacking core elements and redesigning interfaces on the fly there will be no change. Just lots of new features that almost work as long as you use them in a particular way. theres a lot to be said for doing something right the first time and sticking with it even if it isnt perfect. Unfortunately many of the original linux designs were so poorly thought out that they need to be completely redesigned. DB - 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: Topic for discussion: OS Design
On Mon, 23 Oct 2000, Dennis wrote:
o What used to take a month to get working in SunOS, will
take a few hours on Linux. Linux has continually improved the
resources available to the modules. In the beginning there was
a kernel memory allocator. Now we have common resource allocation
code for I/O addresses like PCI, common interrupt handlers, common
sleep and wake-up routines, etc. Basically, the best ideas of
all the driver contributors have been adapted into a kernel-driver
interface so that every compliant module gets to share the best
code available.
As long as your modules are trivial, you are correct. I agree that writing
a basic module is fairly easy, and debugging is easy (although if they
fixed the printk interface it would be easier), but.
Some of the stuff we do is hardly trivial. Could you explan what you
have found wrong with printk()? I have never had any problem with it.
If you are referring to the limited-size buffering of the output, this
is not something that requires a "fix". It is deliberate so that even
and out-of-memory situation can be displayed. Printk()'s buffer is
allocated once and is fixed-length. If you use printk for what it
is supposed to be used for, you will never have any problems.
There are other ways than printk() to write output to the current
task's output. printk() is most useful where there isn't a well-
defined 'current'.
static void print_string(char *str)
{
struct tty_struct *tty = current-tty;
(*tty-driver.write)(tty, 0, str, strlen(str));
(*tty-driver.write)(tty, 0, "\r\n", 2);
}
"compliance" is difficult without good documentation,and unfortunately most
of the docs for the linux kernel are in Alan Cox's head (and the like).
Virtually all books are out of date by the time they hit the shelves (the
linux "device driver" book had many errors and omissions and proved more
detrimental than useful). Most of the how-tos are out of date. This,
understandable, is what you get for free.
Also, the definition of "compliant" keeps changing. the difference between
a real commercial OS and linux is that linux is a moving target.
Look, if you are doing product development, it's counter-productive to
use a __development__ kernel. You can spend too much time keeping up
with the changes. Instead, just like you should never change your tools
during a product design cycle, you should not change the effective
kernel you use.
The "stable" kernel, i.e., 2.2.5 - 2.2.17 has been kept up-to-date
as far as bug fixes are concerned. My drivers work fine in this
series.
At some later date, when the current development kernel becomes
the "stable" kernel, I will make whatever changes are necessary to
my (at last count) 12 drivers so they work in the new kernel.
This is something that will happen during the normal product lifetime,
not before the products are being shipped.
While they might brag about LINUX being "fast moving", it is also the main
reason that it is continuously unstable and the hopes of true stability
any time soon is questionable. Until they stop hacking core elements and
redesigning interfaces on the fly there will be no change. Just lots of new
features that almost work as long as you use them in a particular way.
theres a lot to be said for doing something right the first time and
sticking with it even if it isnt perfect. Unfortunately many of the
original linux designs were so poorly thought out that they need to be
completely redesigned.
Not true. You can't have reviewed or understand any of the kernel code if
you believe this. All major elements are modular. When somebody comes
up with better memory management, it's encorporated, better scheduling,
it's encorporated, etc. This is what development kernels are for.
Bugs that were found when changing the design of various kernel
procedures, have been back-ported to the stable kernel series.
Cheers,
Dick Johnson
Penguin : Linux version 2.2.17 on an i686 machine (801.18 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
-
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: Topic for discussion: OS Design
On Sun, 22 Oct 2000, Dwayne C . Litzenberger wrote: Then I start hearing about khttpd, something that (ideally) should go in user space, hardware drivers are rejected (PCSP is my example, but what if some other device is as kludgy as the pcsp? Will it be rejected too?) PCSP isn't in the kernel because the DRIVER was kludgy. Khttpd is in because it isn't... If you really want a driver for the PC speaker in the kernel, why don't you show your commitment by writing one which isn't kludgy ? Patches for features I want are a nightmare. You may want to consider fixing them. If you're capable of making statements regarding the achitecture of the whole system, surely you'll be able to do such a simple task as cleaning up device drivers? My complaint is from a user's point of view. This particular user wants software-suspend, pcsp, reiserfs, USB, and agpgart. This user also wants a smooth GUI, a mouse pointer that doesn't flinch under load, and a small enough system that he won't have to be swapping all the time (not entirely kernel's fault). All these things are reasonable. Send patches. regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - 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: Topic for discussion: OS Design
This is typical of the "linux mentality". Why do other OSs have solutions
that work, yet linux's method requires special coding? If it "has to be
done that way", why do other OS's have solutions that dont do it that way?
the size of the buffer is an annoyance but not a serious problem however.
printing directly to the console (as BSD does) is useful when debugging a
panic, as you can trace right to the panic point. Also certain levels of
output will trash the screen, requiring a reset (switching to another
virtual console and then switching back, unfortunately flushing the buffer
will do it). Im not sure if it has been fixed, but also writing without a
newline used to cause garbage to be spewed to the screen, which meant a
screen line had to be used for each message.
At 02:08 PM 10/23/2000, Richard B. Johnson wrote:
On Mon, 23 Oct 2000, Dennis wrote:
o What used to take a month to get working in SunOS, will
take a few hours on Linux. Linux has continually improved the
resources available to the modules. In the beginning there was
a kernel memory allocator. Now we have common resource allocation
code for I/O addresses like PCI, common interrupt handlers, common
sleep and wake-up routines, etc. Basically, the best ideas of
all the driver contributors have been adapted into a kernel-driver
interface so that every compliant module gets to share the best
code available.
As long as your modules are trivial, you are correct. I agree that writing
a basic module is fairly easy, and debugging is easy (although if they
fixed the printk interface it would be easier), but.
Some of the stuff we do is hardly trivial. Could you explan what you
have found wrong with printk()? I have never had any problem with it.
If you are referring to the limited-size buffering of the output, this
is not something that requires a "fix". It is deliberate so that even
and out-of-memory situation can be displayed. Printk()'s buffer is
allocated once and is fixed-length. If you use printk for what it
is supposed to be used for, you will never have any problems.
There are other ways than printk() to write output to the current
task's output. printk() is most useful where there isn't a well-
defined 'current'.
static void print_string(char *str)
{
struct tty_struct *tty = current-tty;
(*tty-driver.write)(tty, 0, str, strlen(str));
(*tty-driver.write)(tty, 0, "\r\n", 2);
}
"compliance" is difficult without good documentation,and unfortunately
most
of the docs for the linux kernel are in Alan Cox's head (and the like).
Virtually all books are out of date by the time they hit the shelves (the
linux "device driver" book had many errors and omissions and proved more
detrimental than useful). Most of the how-tos are out of date. This,
understandable, is what you get for free.
Also, the definition of "compliant" keeps changing. the difference
between
a real commercial OS and linux is that linux is a moving target.
Look, if you are doing product development, it's counter-productive to
use a __development__ kernel. You can spend too much time keeping up
with the changes. Instead, just like you should never change your tools
during a product design cycle, you should not change the effective
kernel you use.
The "stable" kernel, i.e., 2.2.5 - 2.2.17 has been kept up-to-date
as far as bug fixes are concerned. My drivers work fine in this
series.
At some later date, when the current development kernel becomes
the "stable" kernel, I will make whatever changes are necessary to
my (at last count) 12 drivers so they work in the new kernel.
This is something that will happen during the normal product lifetime,
not before the products are being shipped.
While they might brag about LINUX being "fast moving", it is also the main
reason that it is continuously unstable and the hopes of true stability
any time soon is questionable. Until they stop hacking core elements and
redesigning interfaces on the fly there will be no change. Just lots of
new
features that almost work as long as you use them in a particular way.
theres a lot to be said for doing something right the first time and
sticking with it even if it isnt perfect. Unfortunately many of the
original linux designs were so poorly thought out that they need to be
completely redesigned.
Not true. You can't have reviewed or understand any of the kernel code if
you believe this. All major elements are modular. When somebody comes
up with better memory management, it's encorporated, better scheduling,
it's encorporated, etc. This is what development kernels are for.
Bugs that were found when changing the design of various kernel
procedures, have been back-ported to the stable kernel series.
I never use development kernels, what Im talking about is each major
release is like starting from version 1.0. By the time it stabilizes, the
next major puts it back to square one.
My point is
Re: Topic for discussion: OS Design
On Sun, 22 Oct 2000, Dwayne C . Litzenberger wrote: This user also wants a smooth GUI, a mouse pointer that doesn't flinch under load, Try andrea archangeli's VM patches. When I use those patches X gets much smoother and xmms (with nice -5) never skips. 2.2 VM sucks, film at 11. and a small enough system that he won't have to be swapping all the time (not entirely kernel's fault). Huh? RAM is cheap. If 128MB of PC133 isn't enough for you, then it isn't the kernel's fault, its your bloated apps. - 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: Topic for discussion: OS Design
On Mon, 23 Oct 2000, Dennis wrote: This is typical of the "linux mentality". Why do other OSs have solutions that work, yet linux's method requires special coding? If it "has to be done that way", why do other OS's have solutions that dont do it that way? the size of the buffer is an annoyance but not a serious problem however. I'm not sure that Linux requires any special coding. printing directly to the console (as BSD does) is useful when debugging a panic, as you can trace right to the panic point. Also certain levels of BSD does not write directly to the console. Its console is a direct clone of Linux. I'm not sure which came first, but when you have a single screen-card there are not too many ways to get the character and attribute into screen memory. Linux allows the console to be redirected to a serial port. BSD does not last time I checked. Bugs that were found when changing the design of various kernel procedures, have been back-ported to the stable kernel series. I never use development kernels, what Im talking about is each major release is like starting from version 1.0. By the time it stabilizes, the next major puts it back to square one. What? The API has remained consistent since 0.99. It's only internal kernel stuff that has changed. If you wrote code that worked on 0.99, it will still compile and work on 2.2.17. You could not have written code for 0.99 that used mmap() and some other stuff because it had not been developed yet. However, all the "Unix stuff" like read/write/open/close/ioctl/lseek, etc., and their buffered versions like fopen() from the 'C' runtime library, have had the same API since day one. Linux was developed, from the start, to have a POSIX compatible API. Most of that API comes from the 'C' runtime library, the exact same API used by BSD and all the other OS's to which the GNU library has been ported. The only reason to get the 'latest' version is to take advantage of increased functionality. This, by definition, means that something has changed. That's what you upgrade for. The word "unstable" is a misnomer. My point is that there is no "stable kernel series". 2.2.0 wasnt stable, and neither was 2.2.3. Virtually all of the ethernet drivers still lock up under heavy load in 2.2.17...and now with 2.4 there are more countless adventures ahead Which Ethernet drivers are you having trouble with? The ones that had lockup problems (incidentally hardware related), now have reset code that runs off a watch-dog. an example of "poor planning" is that skput and skpush will panic the kernel if there is no room (this can happen with multiple encapsulations) The proper behaviour would be to return a NULL pointer indicating failure, and then to drop the frame and issue a warning. The proper response to any resource not being available (in networking) is to drop the packet on the floor, smash it into little pieces, and don't tell anybody about it. The packet will be sent again. But, if you can't transmit a packet, therefore freeing a buffer, what do you do? What you do is realilize that the failure to transmit was likely caused by a disconnected wire. In the drivers I use, I simply pretend that every packet got transmitted okay. This usually involves a one or two-line modification to the driver. This has nothing to do with poor planning. It just has to do with a design decision that I didn't agree with. Somebody decided that network data was precious and therefore the machine should kill itself if necessary to get the data through. I didn't agree with this so I changed a few lines of code. You can't kill any of my machines by flooding them and they never lock up. Further, they run at 85 to 90 percent of the network physical layer bandwidth. My main machine is our domain name-server, it gets between 2000 and 5000 hits per second. If it crashed, our whole LAN goes down. It doesn't. It runs Linux-2.2.17. Script started on Mon Oct 23 16:12:02 2000 # rlogin boneserver Password: Last login: Mon Oct 23 11:28:29 from chaos.analogic.com Linux 2.2.17. [3g[25;9HH[25;17HH[25;25HH[25;33HH[25;41HH[25;49HH[25;57HH[25;65HH[25;73HH )0 # uptime 4:12pm up 24 days, 22:21, 11 users, load average: 0.81, 0.62, 0.00 # exit logout rlogin: connection closed. # exit exit Script done on Mon Oct 23 16:12:27 2000 Those 11 users are all network servers including samba for M$ connectivity. One of the major advantages of Linux is that if you don't like a design decision that was made, you are free to do it over the way you think is right. Sometimes you can convince others that your way is better. Sometimes not. If so, your patch makes it into the main-line kernel, if not, you patch your own future kernels so you get to retain your improvements. FYI, if AC did not exist, another would appear to fill the vacuum. Don't bitch. Make some improvements and send patches. Cheers, Dick Johnson Penguin : Linux version 2.2.17 on
Re: Topic for discussion: OS Design
At 04:35 PM 10/23/2000, you wrote: On Mon, 23 Oct 2000, Dennis wrote: This is typical of the "linux mentality". Why do other OSs have solutions that work, yet linux's method requires special coding? If it "has to be done that way", why do other OS's have solutions that dont do it that way? the size of the buffer is an annoyance but not a serious problem however. I'm not sure that Linux requires any special coding. printing directly to the console (as BSD does) is useful when debugging a panic, as you can trace right to the panic point. Also certain levels of BSD does not write directly to the console. Its console is a direct clone of Linux. I'm not sure which came first, but when you have a single screen-card there are not too many ways to get the character and attribute into screen memory. Linux allows the console to be redirected to a serial port. BSD does not last time I checked. - FreeBSD will display kernel print messages with syslogd not running, and linux will not. - FreeBSD doesnt (seem) to have the buffering problem that linux does, in that exceptionally long messages (like decoding a Frame Relay LMI frame with 1000 elements) work just fine. - FreeBSD will display messages immediately without a newline - FreeBSD messages 1) can be redirected and 2) are printed without a timestamp. which implies that you are wrong about just about everything. What? The API has remained consistent since 0.99. It's only internal kernel stuff that has changed. If you wrote code that worked on 0.99, it will still compile and work on 2.2.17. We are talking about the kernel. What are you talking about? The external view is meaningless. the device driver interface changed substantially in 2.0. The module interface changed, as it is changing again in 2.4. The PCI interface has changed and is changing again. The only reason to get the 'latest' version is to take advantage of increased functionality. This, by definition, means that something has changed. That's what you upgrade for. The word "unstable" is a misnomer. Usually my customers want to upgrade because of some security fix or bug fix, not to get new features. My point is that there is no "stable kernel series". 2.2.0 wasnt stable, and neither was 2.2.3. Virtually all of the ethernet drivers still lock up under heavy load in 2.2.17...and now with 2.4 there are more countless adventures ahead Which Ethernet drivers are you having trouble with? The ones that had lockup problems (incidentally hardware related), now have reset code that runs off a watch-dog. The eepro100 driver is an ongoing project, still with lockup problems. the tulip has issues as well. an example of "poor planning" is that skput and skpush will panic the kernel if there is no room (this can happen with multiple encapsulations) The proper behaviour would be to return a NULL pointer indicating failure, and then to drop the frame and issue a warning. The proper response to any resource not being available (in networking) is to drop the packet on the floor, smash it into little pieces, and don't tell anybody about it. The packet will be sent again. But, if you can't transmit a packet, therefore freeing a buffer, what do you do? What you do is realilize that the failure to transmit was likely caused by a disconnected wire. In the drivers I use, I simply pretend that every packet got transmitted okay. This usually involves a one or two-line modification to the driver. This has nothing to do with poor planning. It just has to do with a design decision that I didn't agree with. Somebody decided that network data was precious and therefore the machine should kill itself if necessary to get the data through. I didn't agree with this so I changed a few lines of code. You can't kill any of my machines by flooding them and they never lock up. Further, they run at 85 to 90 percent of the network physical layer bandwidth. My main machine is our domain name-server, it gets between 2000 and 5000 hits per second. If it crashed, our whole LAN goes down. It doesn't. It runs Linux-2.2.17. Right. So your answer is that linux is OK if you modify all of the broken stuff yourself. Im glad we are in agreement on that, if nothing else. DB - 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: Topic for discussion: OS Design
On Mon, Oct 23, 2000 at 06:43:28PM -0400, Dennis wrote: - FreeBSD will display kernel print messages with syslogd not running, and linux will not. Linux will also when the console log level is set high enough (which it is by default, just it is usually too low after you killed klogd). Unqualified printks have level 4, so you need a level that. Some distributions also unfortunately set bogus defaults or redirect the messages to specific virtual consoles. - FreeBSD doesnt (seem) to have the buffering problem that linux does, in that exceptionally long messages (like decoding a Frame Relay LMI frame with 1000 elements) work just fine. You cannot print more than the kernel log buffers size without scheduling inbetween to let klogd eat some of the buffer. I don't see a way how FreeBSD could do that better, except if they found a way to store infinite data in a finite buffer (or alternatively not store your LMI frame completely in the syslog, which would be also as bad) It is possible that their default buffer is bigger though. Linux's default is 16K, which is a bit on the low side for many things. You can increase it of course with a simple recompile by changing the define in kernel/printk.c Admittedly one problem in Linux with big printks is that it kills your interrupt latency completely. There are lower overhead alternatives though. - FreeBSD will display messages immediately without a newline - FreeBSD messages 1) can be redirected and 2) are printed without a timestamp. Both just like in Linux. The timestamps come from syslogd/klogd, not the kernel. -Andi - 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: Topic for discussion: OS Design + GPL
ftp://ftp.etinc.com/pub/linux/linux22_hdlc.tgz Hi Dennis, Could explain to me why ET Inc is modifying GPL drivers and then republishing the binaries as modules only? Not that it is my sub-system, but I am not sure that my friend Don knows of this issue. If Don does not care then, good day. ls hdlc/usr/hdlc/dev/modules/2.2.14 . eepro100.o etbwmgr.o tulip.o .. eepro100orig.o ethdlc.otuliporig.o Cheers, Andre Hedrick The Linux ATA/IDE guy - 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: Topic for discussion: OS Design
Another linux caveat. Scads of undocumented and virtually undiscoverable behaviours :-) Undiscoverable? You have the source code, what more do you want? Start documenting! - 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: Topic for discussion: OS Design
On Mon, Oct 23, 2000 at 07:43:24PM -0400, Dennis wrote: At 07:19 PM 10/23/2000, Andi Kleen wrote: On Mon, Oct 23, 2000 at 06:43:28PM -0400, Dennis wrote: - FreeBSD will display kernel print messages with syslogd not running, and linux will not. Linux will also when the console log level is set high enough (which it is by default, just it is usually too low after you killed klogd). Unqualified printks have level 4, so you need a level that. Some distributions also unfortunately set bogus defaults or redirect the messages to specific virtual consoles. Another linux caveat. Scads of undocumented and virtually undiscoverable behaviours :-) It is not undocumented. Try reading the klogd manpage. -Andi - 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: Topic for discussion: OS Design
On Mon, 23 Oct 2000, Hacksaw wrote: Another linux caveat. Scads of undocumented and virtually undiscoverable behaviours :-) Undiscoverable? You have the source code, what more do you want? Start documenting! Oh no then they would have to publish their findings, and that is only available in binary format or $500.00 USD and threats for a lawyer. Regardless that the original code was GPL I am BATING someone to answer why they are selling GPL code and making legal gestures if you pay for the GPL code and share the GPL code. Someone must have a harder time than me reading the rules. Cheers, Andre Hedrick The Linux ATA/IDE guy - 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: Topic for discussion: OS Design
FWIW, 'message passing' is the wrong answer to the question 'how do I separate the components of a kernel into distinct modules for ' but that's because it's tied to the Accent ancestry of the Mach style "microkernel". One of the few things we did get right in Brevix was the idea of an interface transition that used the memory management architecture of PA-RISC effectively to give the modularity and production without the overhead of message passing. If you want someone to add components to hardware to support that, get them to set up a system that effectively separates memory addressability from memory accessability, as PA-RISC did. (Oh wait, we did that. If Intel didn't throw it away, Itanium *will* have such an architecture.) Crossing memory protection domains does not need to be slow. It's not in PA-RISC, although it is in the VAX-ish memory architecture of systems like x86. It doesn't have to be in IA-64, if one is willing to abandon 'legacy.' -Original Message- From: Dwayne C . Litzenberger [mailto:[EMAIL PROTECTED]] Sent: Sunday, October 22, 2000 8:57 PM To: Erno Kuusela Cc: [EMAIL PROTECTED] Subject: Re: Topic for discussion: OS Design [snip] > crossing memory protection domains is slow, there's no way around > it (except better hardware). So what we really need to do is get some custom "RAM blitter" into our hardware to do the memory copies needed for fast context switching and message passing. Too bad nobody on this list works at an electronics design company... ;-P -- Dwayne C. Litzenberger - [EMAIL PROTECTED] - Please always Cc to me when replying to me on the lists. - Please have the courtesy to respond to any requests or questions I may have. - See the mail headers for GPG/advertising/homepage information. - 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: Topic for discussion: OS Design
On Sun, Oct 22, 2000 at 09:56:52PM -0600, Dwayne C . Litzenberger wrote: > [snip] > > crossing memory protection domains is slow, there's no way around > > it (except better hardware). > > So what we really need to do is get some custom "RAM blitter" into our > hardware to do the memory copies needed for fast context switching and message > passing. > > Too bad nobody on this list works at an electronics design company... ;-P Dwayne, Why don't you get with the C++ guy on the list talking about C++ kernels, Eray Ozkural ([EMAIL PROTECTED]) and the two of you design a processor that's optimized to run C++ with 0 overhead memory protection (3 clocks max to go through a ring 3 -> 0 gate). Who knows? Maybe you could design a new processor for us to use that just implements two super RISC instructions, 'set bugs off' and 'do what I'm thinking'. :-) Jeff > > -- > Dwayne C. Litzenberger - [EMAIL PROTECTED] > > - Please always Cc to me when replying to me on the lists. > - Please have the courtesy to respond to any requests or questions I may have. > - See the mail headers for GPG/advertising/homepage information. - 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: Topic for discussion: OS Design
I'll explain my reason for this rant. The Amiga was my second computer, and the one I spend most of my computing life on. I've grown up noticing all the things the PC/Windows did wrong while the Amiga did it right (mostly UI stuff). Later, I got my own PC, running Windows 95. Horror. Win95 is an absolutely bug-infested piece of you-know-what. However, at that time, I believed that Windows==PC, so I thought it was the PC hardware that was at fault. Then, I heard of Linux, and installed it. What a difference! Much faster, and sooo stable! I loved it. It was still clunky, and slow (compare a P120MHz to an Amiga 7.14Mhz -- should be 16x as fast, but it's not), but I still thought it was because of the PC hardware. Executable code sizes bugged me a bit (usually 10-100x larger than Amiga). Then I got the QNX demodisk. It was amazing what they could fit on that disk! It was also smooth and fast, too. I started to doubt that the PC hardware was solely at fault for the inefficiency of the software running on it. Later, I downloaded the actual QNX RTOS CD (go try it: http://get.qnx.com/), and this confirmed my suspicions that PC hardware was capable of relatively efficient operation. So, then, I was asking myself: WHY is Linux so slow and clunky in comparison? I knew that GCC was not the most efficient compiler in the world, but it wasn't that bad. Then I start hearing about khttpd, something that (ideally) should go in user space, hardware drivers are rejected (PCSP is my example, but what if some other device is as kludgy as the pcsp? Will it be rejected too?), and software-suspend mysteriously disappears from Alan's -ac patches. X (a hardware driver) is in user space, and so is svgalib. It all looks very messy. The atyfb still doesn't work for my Rage Pro (2.2.x, anyway. Never tried 2.[34]). Patches for features I want are a nightmare. My complaint is from a user's point of view. This particular user wants software-suspend, pcsp, reiserfs, USB, and agpgart. This user also wants a smooth GUI, a mouse pointer that doesn't flinch under load, and a small enough system that he won't have to be swapping all the time (not entirely kernel's fault). All these things are reasonable. Somebody here with a bit more knowledge should really take an hard look at QNX. From a user's standpoint, it's a very clean and efficient (fast) OS. Is it possible to have something that is as clean as a microkernel, while minimizing the overhead? I must apologize for saying what seemed to be another "Linux should be a microkernel". That was not my intent. I indended to start a discussion (!argument) about looking for the best of both worlds (or a new idea altogether) of monolithic and micro- kernels. -- Dwayne C. Litzenberger - [EMAIL PROTECTED] - Please always Cc to me when replying to me on the lists. - Please have the courtesy to respond to any requests or questions I may have. - See the mail headers for GPG/advertising/homepage information. PGP signature
Re: Topic for discussion: OS Design
[snip] > crossing memory protection domains is slow, there's no way around > it (except better hardware). So what we really need to do is get some custom "RAM blitter" into our hardware to do the memory copies needed for fast context switching and message passing. Too bad nobody on this list works at an electronics design company... ;-P -- Dwayne C. Litzenberger - [EMAIL PROTECTED] - Please always Cc to me when replying to me on the lists. - Please have the courtesy to respond to any requests or questions I may have. - See the mail headers for GPG/advertising/homepage information. PGP signature
Re: Topic for discussion: OS Design
On Sun, 22 Oct 2000, Dwayne C . Litzenberger wrote: >Although I am a programmer, I am not yet a kernel hacker, so some of my claims Point 1. >*very* efficient. However, there are some drawbacks to microkernels that have >been raised Point 2. >(and I don't have the expertise to argue about them), Point 3. That pretty much answers the question right there IMHO. This is an FAQ. >So, my question is this: What are some of Linux's design problems, and what >fundamental changes could be made for a long-run benefit? Not by turning it into a microkernel. Suggesting it is nothing more than religious CS BS. -- Mike A. Harris - Linux advocate - Open source advocate Computer Consultant - Capslock Consulting Copyright 2000 all rights reserved -- [Mike A. Harris Linux tip #1 - 50 line mode] Is the 80x25 line screen too small for you? If you want more screen real estate, you can set 50 column mode by editing your /etc/lilo.conf file, and adding a new line with "vga=ext" to the global section near the top. Save and exit, then run "lilo". Next time you boot, you'll have a nice big 80x50 screen. - 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: Topic for discussion: OS Design
On Sun, Oct 22, 2000 at 04:58:45PM -0600, Dwayne C . Litzenberger wrote: > Could you elaborate? AFAIK, both Neutrino and exec.library are microkernels, > and they by no means lack performance. Even Windows is a microkernel (sort > of), and it doesn't lack in performance that much. Exec.library with it's aproximately 6kb can hardly be compared with a full featured kernel like Linux. Look at something like filesystems. If you write a multithreaded filesystem for the Amiga you'll hit alot of complexity which you'll never have to think about for a monolithic kernel. Makes monolithic kernels look sweet as sugar in comparison. Ralf - 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: Topic for discussion: OS Design
In article <[EMAIL PROTECTED]> you wrote: > A few years ago, there was an intense debate around the question of > cooperative vs. preemptive multitasking operating system design. Today, > however, cooperative multitasking is a thing of the past, and it is virtual= > ly > undisputed that the preemptive multitasking design is highly superior to the > cooperative one. No, this completely depends on the Task the OS has to do and the Hardware the OS has to run on. Cooperative Systems can have a lot more throughput than time sliced systems. > It would seem that a microkernel design would fix most of these problems. = > Two > very elegant operating systems, namely the Amiga's exec.library and QNX's > Neutrino (I'm sure you can name others), used microkernels, and they were b= > oth > *very* efficient. The problem is, that Linux is not a Microkernel Based System. So if you want a microkernel based system ust used one. There are lot out there. Based on MACH or whatever. You can consier to work with the HURD. I mean it is not a bad idea to rethink design of the Linux Kernel, but changing it into a Microkernel means rewriting it. And I am not sure it will helo the Linux development a lot (remeber ist WAS the fastest among all others, this can be due to the fact that the monolitic kernel is supperior in development effords). Grettings Bernd - 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: Topic for discussion: OS Design
[EMAIL PROTECTED] proclaimed... > Could you elaborate? AFAIK, both Neutrino and exec.library are > microkernels, and they by no means lack performance. Whilst I've not used Neutrino, I did use exec.library for several years (and was part of a project to rewrite the bad parts before CBM went down the pan). I'm not sure the point you're trying to make. AmigaOS had Device drivers in userspace (Well, AmigaOS didn't really have a kernel/user space divide), which generally worked ok for the Amiga, but are not practical in Linux. - AmigaOS didn't have to worry about issues like SMP. Linux runs on archs other than m68k, where we _do_ have to worry about such things. - AmigaOS had no memory protection, and no concept of userspace/kernelspace, so it was perfectly acceptable for a userspace driver to handle interrupts etc, bash hardware registers etc.. Linux (on x86 for example) has to run priveledged instructions in kernel mode, which require a context switch. If you really think AmigaOS has anything which Linux could benefit from, send patches. Otherwise, well... > Even Windows is a microkernel (sort of) > and it doesn't lack in performance that much. This doesn't even justify a reply. Please go read an OS internals book before you make such comments. regards, d. -- | Dave Jones <[EMAIL PROTECTED]> http://www.suse.de/~davej | SuSE Labs - 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: Topic for discussion: OS Design
Yikes! Within 5 minutes, I already got a few personal attacks! (and some very insightful messages as well.) I'll end this here before it gets too out-of-control. I should have done my homework before posting. I don't totally agree that my posts were wrong (as an end user, I can definitely see that Linux needs serious work), but I should have seen that this would start a flame war, and been sufficiently armed to enter into an argument like this. I'm not, so I'll just shut up now. -> Please don't continue to flame me: I've learned my lesson. <- I'm a teenager that's been programming (mostly in AmigaBASIC) for about 11 years now. I've only been doing C for the last 1-2 years (though I'm learning quickly). I want to get familiar with kernel programming. I've been told that I should start with writing a driver. Any good online resources on doing this (eg. hardware specs, x86 assembler resources, tutorials, etc)? I learn quickly, but I have no idea where to begin. -- Dwayne C. Litzenberger - [EMAIL PROTECTED] - Please always Cc to me when replying to me on the lists. - Please have the courtesy to respond to any requests or questions I may have. - See the mail headers for GPG/advertising/homepage information. PGP signature
Re: Topic for discussion: OS Design
On Mon, Oct 23, 2000 at 08:53:26AM +1000, Peter Waltenberg wrote: > Use the GNU Hurd, it won't run on most hardware you'd like to use, and it's > probably slower than Linux, but it's a microkernel. I'll ignore that. > I've worked with microkernels, IMHO, they suck :). Good idea, but fundamentally > flawed. The same things that make them more robust (and they are more robust) > also kill performance. Could you elaborate? AFAIK, both Neutrino and exec.library are microkernels, and they by no means lack performance. Even Windows is a microkernel (sort of), and it doesn't lack in performance that much. -- Dwayne C. Litzenberger - [EMAIL PROTECTED] - Please always Cc to me when replying to me on the lists. - Please have the courtesy to respond to any requests or questions I may have. - See the mail headers for GPG/advertising/homepage information. PGP signature
Re: Topic for discussion: OS Design
> "Dwayne" == Dwayne C Litzenberger <[EMAIL PROTECTED]> writes: Dwayne> First of all, I'd like to say that I'm not writing this to Dwayne> piss anyone off. It's not a flame, a troll, or a personal Dwayne> attack on anyone. I my writing will aid in the improvement of Dwayne> Linux. Please read this with as much neutrality as you can Dwayne> summon. Oh my, not another one of those ;-( Lets try and kill this on on the rise and avoid another flame war caused by someone who hasn't tried to write single line of code on his own. Dwayne> Linux's loadable modules design is insufficient. I have Dwayne> several reasons for making this claim: Dwayne> 1. Many things are inaccessible to the modules: There are Dwayne> relatively few kernel modifications that can be compiled Dwayne> without patching the pristine sources. Your point being? Dwayne> 2. The modules API is unstable. Some people say this is Dwayne> because of the exceedingly rapid development cycle of Linux. Dwayne> I beg to differ. I believe it is because there is no real Dwayne> planned structure in the API -- just passing highly volatile Dwayne> internal data structures around. And this is a good thing, we want an efficient API not something that people are afraid to break in order to solve problems - if we have a bug or we can improve the API we should improve the API. Yes you can claim you can design your way out of everything and everybody who's written real code knows thats not the case. Code and design is an iterative proces. Dwayne> 3. Modules can very easily crash the whole kernel. This is Dwayne> because each module does not get to run in its own protected Dwayne> memory space, as it would in a well-designed microkernel. Oh my, did you just take the first lecture in a junior OS course? Putting them in their own protected memory space is a) similar to putting things in user space except for interrupt handling and b) very inefficient for passing data around inside the kenel. The next lecture in your course should cover context switches and page table modifications and the cost of these. Dwayne> 4. The kernel HTTPD is just masking a slow networking design. Dwayne> Yes, I agree that high-level protocols should be eventually Dwayne> incorporated into a standardized interface in an operating Dwayne> system. However, there would be no need for a kernel-based Dwayne> httpd if the kernel was efficient enough. This leads into my Dwayne> next point: Which kernel httpd? tux or khttpd? Tux is designed for the specweb pissing contest, thats what specweb is all about. khttpd should be replaced by something like phttpd which is a sigio based web server. The performance has little to do with the networking design. Dwayne> 5. Linus tends to blame patches for inadequacies in the Dwayne> kernel. The PC speaker driver is a perfect example: No driver Dwayne> should have to do something "dirty" in order to function, Dwayne> because the operating system should provide clean ways to do Dwayne> this. A lot of drivers are badly designed and a lot of hardware is badly designed, in particular PC hardware ;-( I don't know the details on the PC speaker driver, but it is clearly something dear to you. Dwayne> It would seem that a microkernel design would fix most of Dwayne> these problems. Two very elegant operating systems, namely Dwayne> the Amiga's exec.library and QNX's Neutrino (I'm sure you can Dwayne> name others), used microkernels, and they were both *very* Dwayne> efficient. However, there are some drawbacks to microkernels Dwayne> that have been raised (and I don't have the expertise to argue Dwayne> about them), but I think there are enough intelligent people Dwayne> here that we can come up with a new OS design that takes the Dwayne> best from both worlds. This may require a new mailing list. And if you had done your homework you would also know that exec.library is based on running in a single shared memory space. There is a reason why micro kernels are practically dead. Dwayne> So, my question is this: What are some of Linux's design Dwayne> problems, and what fundamental changes could be made for a Dwayne> long-run benefit? Actually one of the biggest problems we have is the noise ratio caused by people not doing their homework and then raising issues on the list expecting everybody to take them serious. Jes - 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: Topic for discussion: OS Design
"Dwayne" == Dwayne C Litzenberger [EMAIL PROTECTED] writes: Dwayne First of all, I'd like to say that I'm not writing this to Dwayne piss anyone off. It's not a flame, a troll, or a personal Dwayne attack on anyone. I my writing will aid in the improvement of Dwayne Linux. Please read this with as much neutrality as you can Dwayne summon. Oh my, not another one of those ;-( Lets try and kill this on on the rise and avoid another flame war caused by someone who hasn't tried to write single line of code on his own. Dwayne Linux's loadable modules design is insufficient. I have Dwayne several reasons for making this claim: Dwayne 1. Many things are inaccessible to the modules: There are Dwayne relatively few kernel modifications that can be compiled Dwayne without patching the pristine sources. Your point being? Dwayne 2. The modules API is unstable. Some people say this is Dwayne because of the exceedingly rapid development cycle of Linux. Dwayne I beg to differ. I believe it is because there is no real Dwayne planned structure in the API -- just passing highly volatile Dwayne internal data structures around. And this is a good thing, we want an efficient API not something that people are afraid to break in order to solve problems - if we have a bug or we can improve the API we should improve the API. Yes you can claim you can design your way out of everything and everybody who's written real code knows thats not the case. Code and design is an iterative proces. Dwayne 3. Modules can very easily crash the whole kernel. This is Dwayne because each module does not get to run in its own protected Dwayne memory space, as it would in a well-designed microkernel. Oh my, did you just take the first lecture in a junior OS course? Putting them in their own protected memory space is a) similar to putting things in user space except for interrupt handling and b) very inefficient for passing data around inside the kenel. The next lecture in your course should cover context switches and page table modifications and the cost of these. Dwayne 4. The kernel HTTPD is just masking a slow networking design. Dwayne Yes, I agree that high-level protocols should be eventually Dwayne incorporated into a standardized interface in an operating Dwayne system. However, there would be no need for a kernel-based Dwayne httpd if the kernel was efficient enough. This leads into my Dwayne next point: Which kernel httpd? tux or khttpd? Tux is designed for the specweb pissing contest, thats what specweb is all about. khttpd should be replaced by something like phttpd which is a sigio based web server. The performance has little to do with the networking design. Dwayne 5. Linus tends to blame patches for inadequacies in the Dwayne kernel. The PC speaker driver is a perfect example: No driver Dwayne should have to do something "dirty" in order to function, Dwayne because the operating system should provide clean ways to do Dwayne this. A lot of drivers are badly designed and a lot of hardware is badly designed, in particular PC hardware ;-( I don't know the details on the PC speaker driver, but it is clearly something dear to you. Dwayne It would seem that a microkernel design would fix most of Dwayne these problems. Two very elegant operating systems, namely Dwayne the Amiga's exec.library and QNX's Neutrino (I'm sure you can Dwayne name others), used microkernels, and they were both *very* Dwayne efficient. However, there are some drawbacks to microkernels Dwayne that have been raised (and I don't have the expertise to argue Dwayne about them), but I think there are enough intelligent people Dwayne here that we can come up with a new OS design that takes the Dwayne best from both worlds. This may require a new mailing list. And if you had done your homework you would also know that exec.library is based on running in a single shared memory space. There is a reason why micro kernels are practically dead. Dwayne So, my question is this: What are some of Linux's design Dwayne problems, and what fundamental changes could be made for a Dwayne long-run benefit? Actually one of the biggest problems we have is the noise ratio caused by people not doing their homework and then raising issues on the list expecting everybody to take them serious. Jes - 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: Topic for discussion: OS Design
On Mon, Oct 23, 2000 at 08:53:26AM +1000, Peter Waltenberg wrote: Use the GNU Hurd, it won't run on most hardware you'd like to use, and it's probably slower than Linux, but it's a microkernel. I'll ignore that. I've worked with microkernels, IMHO, they suck :). Good idea, but fundamentally flawed. The same things that make them more robust (and they are more robust) also kill performance. Could you elaborate? AFAIK, both Neutrino and exec.library are microkernels, and they by no means lack performance. Even Windows is a microkernel (sort of), and it doesn't lack in performance that much. -- Dwayne C. Litzenberger - [EMAIL PROTECTED] - Please always Cc to me when replying to me on the lists. - Please have the courtesy to respond to any requests or questions I may have. - See the mail headers for GPG/advertising/homepage information. PGP signature
Re: Topic for discussion: OS Design
Yikes! Within 5 minutes, I already got a few personal attacks! (and some very insightful messages as well.) I'll end this here before it gets too out-of-control. I should have done my homework before posting. I don't totally agree that my posts were wrong (as an end user, I can definitely see that Linux needs serious work), but I should have seen that this would start a flame war, and been sufficiently armed to enter into an argument like this. I'm not, so I'll just shut up now. - Please don't continue to flame me: I've learned my lesson. - I'm a teenager that's been programming (mostly in AmigaBASIC) for about 11 years now. I've only been doing C for the last 1-2 years (though I'm learning quickly). I want to get familiar with kernel programming. I've been told that I should start with writing a driver. Any good online resources on doing this (eg. hardware specs, x86 assembler resources, tutorials, etc)? I learn quickly, but I have no idea where to begin. -- Dwayne C. Litzenberger - [EMAIL PROTECTED] - Please always Cc to me when replying to me on the lists. - Please have the courtesy to respond to any requests or questions I may have. - See the mail headers for GPG/advertising/homepage information. PGP signature
Re: Topic for discussion: OS Design
[EMAIL PROTECTED] proclaimed... Could you elaborate? AFAIK, both Neutrino and exec.library are microkernels, and they by no means lack performance. Whilst I've not used Neutrino, I did use exec.library for several years (and was part of a project to rewrite the bad parts before CBM went down the pan). I'm not sure the point you're trying to make. AmigaOS had Device drivers in userspace (Well, AmigaOS didn't really have a kernel/user space divide), which generally worked ok for the Amiga, but are not practical in Linux. - AmigaOS didn't have to worry about issues like SMP. Linux runs on archs other than m68k, where we _do_ have to worry about such things. - AmigaOS had no memory protection, and no concept of userspace/kernelspace, so it was perfectly acceptable for a userspace driver to handle interrupts etc, bash hardware registers etc.. Linux (on x86 for example) has to run priveledged instructions in kernel mode, which require a context switch. If you really think AmigaOS has anything which Linux could benefit from, send patches. Otherwise, well... Even Windows is a microkernel (sort of) and it doesn't lack in performance that much. This doesn't even justify a reply. Please go read an OS internals book before you make such comments. regards, d. -- | Dave Jones [EMAIL PROTECTED] http://www.suse.de/~davej | SuSE Labs - 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: Topic for discussion: OS Design
In article [EMAIL PROTECTED] you wrote: A few years ago, there was an intense debate around the question of cooperative vs. preemptive multitasking operating system design. Today, however, cooperative multitasking is a thing of the past, and it is virtual= ly undisputed that the preemptive multitasking design is highly superior to the cooperative one. No, this completely depends on the Task the OS has to do and the Hardware the OS has to run on. Cooperative Systems can have a lot more throughput than time sliced systems. It would seem that a microkernel design would fix most of these problems. = Two very elegant operating systems, namely the Amiga's exec.library and QNX's Neutrino (I'm sure you can name others), used microkernels, and they were b= oth *very* efficient. The problem is, that Linux is not a Microkernel Based System. So if you want a microkernel based system ust used one. There are lot out there. Based on MACH or whatever. You can consier to work with the HURD. I mean it is not a bad idea to rethink design of the Linux Kernel, but changing it into a Microkernel means rewriting it. And I am not sure it will helo the Linux development a lot (remeber ist WAS the fastest among all others, this can be due to the fact that the monolitic kernel is supperior in development effords). Grettings Bernd - 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: Topic for discussion: OS Design
On Sun, Oct 22, 2000 at 04:58:45PM -0600, Dwayne C . Litzenberger wrote: Could you elaborate? AFAIK, both Neutrino and exec.library are microkernels, and they by no means lack performance. Even Windows is a microkernel (sort of), and it doesn't lack in performance that much. Exec.library with it's aproximately 6kb can hardly be compared with a full featured kernel like Linux. Look at something like filesystems. If you write a multithreaded filesystem for the Amiga you'll hit alot of complexity which you'll never have to think about for a monolithic kernel. Makes monolithic kernels look sweet as sugar in comparison. Ralf - 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: Topic for discussion: OS Design
On Sun, 22 Oct 2000, Dwayne C . Litzenberger wrote: Although I am a programmer, I am not yet a kernel hacker, so some of my claims Point 1. *very* efficient. However, there are some drawbacks to microkernels that have been raised Point 2. (and I don't have the expertise to argue about them), Point 3. That pretty much answers the question right there IMHO. This is an FAQ. So, my question is this: What are some of Linux's design problems, and what fundamental changes could be made for a long-run benefit? Not by turning it into a microkernel. Suggesting it is nothing more than religious CS BS. -- Mike A. Harris - Linux advocate - Open source advocate Computer Consultant - Capslock Consulting Copyright 2000 all rights reserved -- [Mike A. Harris Linux tip #1 - 50 line mode] Is the 80x25 line screen too small for you? If you want more screen real estate, you can set 50 column mode by editing your /etc/lilo.conf file, and adding a new line with "vga=ext" to the global section near the top. Save and exit, then run "lilo". Next time you boot, you'll have a nice big 80x50 screen. - 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: Topic for discussion: OS Design
[snip] crossing memory protection domains is slow, there's no way around it (except better hardware). So what we really need to do is get some custom "RAM blitter" into our hardware to do the memory copies needed for fast context switching and message passing. Too bad nobody on this list works at an electronics design company... ;-P -- Dwayne C. Litzenberger - [EMAIL PROTECTED] - Please always Cc to me when replying to me on the lists. - Please have the courtesy to respond to any requests or questions I may have. - See the mail headers for GPG/advertising/homepage information. PGP signature
Re: Topic for discussion: OS Design
I'll explain my reason for this rant. The Amiga was my second computer, and the one I spend most of my computing life on. I've grown up noticing all the things the PC/Windows did wrong while the Amiga did it right (mostly UI stuff). Later, I got my own PC, running Windows 95. Horror. Win95 is an absolutely bug-infested piece of you-know-what. However, at that time, I believed that Windows==PC, so I thought it was the PC hardware that was at fault. Then, I heard of Linux, and installed it. What a difference! Much faster, and sooo stable! I loved it. It was still clunky, and slow (compare a P120MHz to an Amiga 7.14Mhz -- should be 16x as fast, but it's not), but I still thought it was because of the PC hardware. Executable code sizes bugged me a bit (usually 10-100x larger than Amiga). Then I got the QNX demodisk. It was amazing what they could fit on that disk! It was also smooth and fast, too. I started to doubt that the PC hardware was solely at fault for the inefficiency of the software running on it. Later, I downloaded the actual QNX RTOS CD (go try it: http://get.qnx.com/), and this confirmed my suspicions that PC hardware was capable of relatively efficient operation. So, then, I was asking myself: WHY is Linux so slow and clunky in comparison? I knew that GCC was not the most efficient compiler in the world, but it wasn't that bad. Then I start hearing about khttpd, something that (ideally) should go in user space, hardware drivers are rejected (PCSP is my example, but what if some other device is as kludgy as the pcsp? Will it be rejected too?), and software-suspend mysteriously disappears from Alan's -ac patches. X (a hardware driver) is in user space, and so is svgalib. It all looks very messy. The atyfb still doesn't work for my Rage Pro (2.2.x, anyway. Never tried 2.[34]). Patches for features I want are a nightmare. My complaint is from a user's point of view. This particular user wants software-suspend, pcsp, reiserfs, USB, and agpgart. This user also wants a smooth GUI, a mouse pointer that doesn't flinch under load, and a small enough system that he won't have to be swapping all the time (not entirely kernel's fault). All these things are reasonable. Somebody here with a bit more knowledge should really take an hard look at QNX. From a user's standpoint, it's a very clean and efficient (fast) OS. Is it possible to have something that is as clean as a microkernel, while minimizing the overhead? I must apologize for saying what seemed to be another "Linux should be a microkernel". That was not my intent. I indended to start a discussion (!argument) about looking for the best of both worlds (or a new idea altogether) of monolithic and micro- kernels. -- Dwayne C. Litzenberger - [EMAIL PROTECTED] - Please always Cc to me when replying to me on the lists. - Please have the courtesy to respond to any requests or questions I may have. - See the mail headers for GPG/advertising/homepage information. PGP signature
Re: Topic for discussion: OS Design
On Sun, Oct 22, 2000 at 09:56:52PM -0600, Dwayne C . Litzenberger wrote: [snip] crossing memory protection domains is slow, there's no way around it (except better hardware). So what we really need to do is get some custom "RAM blitter" into our hardware to do the memory copies needed for fast context switching and message passing. Too bad nobody on this list works at an electronics design company... ;-P Dwayne, Why don't you get with the C++ guy on the list talking about C++ kernels, Eray Ozkural ([EMAIL PROTECTED]) and the two of you design a processor that's optimized to run C++ with 0 overhead memory protection (3 clocks max to go through a ring 3 - 0 gate). Who knows? Maybe you could design a new processor for us to use that just implements two super RISC instructions, 'set bugs off' and 'do what I'm thinking'. :-) Jeff -- Dwayne C. Litzenberger - [EMAIL PROTECTED] - Please always Cc to me when replying to me on the lists. - Please have the courtesy to respond to any requests or questions I may have. - See the mail headers for GPG/advertising/homepage information. - 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: Topic for discussion: OS Design
FWIW, 'message passing' is the wrong answer to the question 'how do I separate the components of a kernel into distinct modules for mumble' but that's because it's tied to the Accent ancestry of the Mach style "microkernel". One of the few things we did get right in Brevix was the idea of an interface transition that used the memory management architecture of PA-RISC effectively to give the modularity and production without the overhead of message passing. If you want someone to add components to hardware to support that, get them to set up a system that effectively separates memory addressability from memory accessability, as PA-RISC did. (Oh wait, we did that. If Intel didn't throw it away, Itanium *will* have such an architecture.) Crossing memory protection domains does not need to be slow. It's not in PA-RISC, although it is in the VAX-ish memory architecture of systems like x86. It doesn't have to be in IA-64, if one is willing to abandon 'legacy.' -Original Message- From: Dwayne C . Litzenberger [mailto:[EMAIL PROTECTED]] Sent: Sunday, October 22, 2000 8:57 PM To: Erno Kuusela Cc: [EMAIL PROTECTED] Subject: Re: Topic for discussion: OS Design [snip] crossing memory protection domains is slow, there's no way around it (except better hardware). So what we really need to do is get some custom "RAM blitter" into our hardware to do the memory copies needed for fast context switching and message passing. Too bad nobody on this list works at an electronics design company... ;-P -- Dwayne C. Litzenberger - [EMAIL PROTECTED] - Please always Cc to me when replying to me on the lists. - Please have the courtesy to respond to any requests or questions I may have. - See the mail headers for GPG/advertising/homepage information. - 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/
