I need an answer from Torvalds
So, Linus, when I get done porting 1.2.13 to my assembler-in-Bash, do you want me calling it "Linux"? The scheduler will be a bit more nimble, of course, there will be a 3-stack Forth-like interface to kernelspace, and the meta-superuser will run in Forreal Mode, the true 32-bit-unprotected mode I discovered on the 386. But other than that it'll be "an old time-sharing system", to use the Bell Labs description. The curious should investigate the Forreal.tgz package in cLIeNUX/interim. Rick Hohensee = MOBI ReCam DVR Surveillance Software Powerful PC software to centrally manage, record, analyze and create web pages for multiple cameras with advanced monitoring and notification features to keep you informed while you're away. http://a8-asy.a8ww.net/a8-ads/adftrclick?redirectid=6d43ae384029514ddabc58a6ec7e11e9 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
I need an answer from Torvalds
So, Linus, when I get done porting 1.2.13 to my assembler-in-Bash, do you want me calling it Linux? The scheduler will be a bit more nimble, of course, there will be a 3-stack Forth-like interface to kernelspace, and the meta-superuser will run in Forreal Mode, the true 32-bit-unprotected mode I discovered on the 386. But other than that it'll be an old time-sharing system, to use the Bell Labs description. The curious should investigate the Forreal.tgz package in cLIeNUX/interim. Rick Hohensee = MOBI ReCam DVR Surveillance Software Powerful PC software to centrally manage, record, analyze and create web pages for multiple cameras with advanced monitoring and notification features to keep you informed while you're away. http://a8-asy.a8ww.net/a8-ads/adftrclick?redirectid=6d43ae384029514ddabc58a6ec7e11e9 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why Plan 9 C compilers don't have asm("")
I replied to davem at length but I think I forgot to "reply to all recipients". The gist of it is Forth code density is so high on Forth hardware that things like icaches aren't as important, and the factors involved are entirely different. Like high-performance Forth engines are tiny and draw negligible current. Two URL's... http://forth.gsfc.nasa.gov/ http://www.mindspring.com/chipchuck/forth.html Rick Hohensee www.clienux.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why Plan 9 C compilers don't have asm("")
>Cort Dougan writes: > > I'm talking about _modern_ processors, not processors that dominate >the > > modern age. This isn't x86. > >Linus mentioned Alpha specifically. I don't see how any of the things >he said were x86-centric in any way shape or form. > >All of his examples are entirely accurate on sparc64 for example, and >to even moreso his Alpha commentary can nearly directly be applied to >the MIPS. > >Calls suck ass, even on modern cpus. I've seen several hundreds of > Modern? How many stacks? There's a couple of Forth engines out there that pay the usual for a call and get returns in zero time. Forth code, and Forth engine machine instructions, have about twice as many calls as Linux code, proportionately. Therefor, a return on some designs is one bit in every instruction. Every instruction is "...and maybe do a return in parallel." Forth engines don't have caches. They have on-chip stacks, or the Novix has separate busses to the stacks. Both stacks, return and data. Forth chips aren't modern in the true-multi-user sense, but if an individual were to design such a beast they could get several of them, hundreds maybe, on FPGAs available now. Such things are coming, because a Forth chip IS something an individual can design. Rick Hohensee www.clienux.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why Plan 9 C compilers don't have asm()
Cort Dougan writes: I'm talking about _modern_ processors, not processors that dominate the modern age. This isn't x86. Linus mentioned Alpha specifically. I don't see how any of the things he said were x86-centric in any way shape or form. All of his examples are entirely accurate on sparc64 for example, and to even moreso his Alpha commentary can nearly directly be applied to the MIPS. Calls suck ass, even on modern cpus. I've seen several hundreds of Modern? How many stacks? There's a couple of Forth engines out there that pay the usual for a call and get returns in zero time. Forth code, and Forth engine machine instructions, have about twice as many calls as Linux code, proportionately. Therefor, a return on some designs is one bit in every instruction. Every instruction is ...and maybe do a return in parallel. Forth engines don't have caches. They have on-chip stacks, or the Novix has separate busses to the stacks. Both stacks, return and data. Forth chips aren't modern in the true-multi-user sense, but if an individual were to design such a beast they could get several of them, hundreds maybe, on FPGAs available now. Such things are coming, because a Forth chip IS something an individual can design. Rick Hohensee www.clienux.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why Plan 9 C compilers don't have asm()
I replied to davem at length but I think I forgot to reply to all recipients. The gist of it is Forth code density is so high on Forth hardware that things like icaches aren't as important, and the factors involved are entirely different. Like high-performance Forth engines are tiny and draw negligible current. Two URL's... http://forth.gsfc.nasa.gov/ http://www.mindspring.com/chipchuck/forth.html Rick Hohensee www.clienux.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why Plan 9 C compilers don't have asm("")
>Now, you could probably argue that instead of inline asms we should have >more flexibility in doing a per-callee calling convention. That would be >good too, no question about it. > >Linus > Today's flamebait has been postponed. Happy July 4th. Peace. Rick Hohensee www.clienux.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why Plan 9 C compilers don't have asm("")
> > On Tue, Jul 03, 2001 at 11:37:28PM -0400, Rick Hohensee wrote: > > That's with the GNU tools, without asm(), and without proper declaration > > of printf, as is my tendency. I don't actually return an int either, do I? > > LAAETTR. > > Under ISO C rules, this is illegal, since you must have a proper prototype in > scope when calling variable argument functions. In fact, I have worked on > several GCC ports, where the compiler uses a different calling sequence for > variable argument functions than it does for normal functions. For example, on > the Mips, if the first argument is floating point and the number of arguments > is not variable, it is passed in a FP register, instead of an integer > register. For variable argument functions, everything is passed in the integer > registers. > I didn't know that, but... You seem to be saying the use of assumptions about args passing is non-standard. I know. It's more standard than GNU extensions to C though, C_labels_in_asms in particular, and even in your examples it appears that the particular function abusing these tenets will know what it can expect from a particular compiler, since it knows what it's arguments are. It can't know what it can expect from any compiler. This perhaps is where #ifdef comes in, or similar. Well, it's not more standard than GNU, but the differences would be less detailed in the case of just dealing with various args passing schemes, and there may be some compiler-to-compiler overlap, where there won't be any with stuff like C_labels_in_asms. It's illegal to not declare main() as int. I don't know of a unix that actually passes anything but a byte to the calling process. I got flamed mightily for this in comp.unix.programmer until people ran some checks on thier big Real Unix(TM) boxes of various types. Linux won't pass void either, you have to get a 0 at least. Compliance is subjective. It's easier when things make sense. Rick Hohensee www.clienux.com > -- > Michael Meissner, Red Hat, Inc. (GCC group) > PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA > Work: [EMAIL PROTECTED] phone: +1 978-486-9304 > Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why Plan 9 C compilers don't have asm("")
>> >Cort Dugan >> There isn't such a crippling difference between straight-line and code >>with> >> unconditional branches in it with modern processors. In fact, there's> >>very >> little measurable difference. >> >> If you're looking for something to blame hurd performance on I'd >>suggest >> the entire design of Mach, not inline asm vs procedure calls. Tossing >>a >> few context switches into calls is a lot more expensive. > hpa >That's not where the bulk of the penalty of a function call comes in >(and it's a call/return, not an unconditional branch.) The penalty >comes in because of the additional need to obey the calling >convention, and from the icache discontinuity. > call/return is two unconditional branches and a push and a pop (is that right?), which is I think what CD means, i.e. in terms of branch prediction. The push/pop is a hit on old CPUs, donno about >386. You're right though. The big hit is you can't lose the pushes to set up the args for a separately assembled function, or the frame drop that follows it. >Not to mention that certain things simply cannot be done that way. > Don't tell me that. Then I can't use my subroutine-threaded Forth variant, in which + is a subroutine call. ;o) Anyway, yes it's a performance hit to not inline asms. Is it worth the bletchery? It's worth asking that once in a while. I've looked at set_bit both ways. Now I'm curious how it does as straight C. Rick Hohensee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why Plan 9 C compilers don't have asm()
Cort Dugan There isn't such a crippling difference between straight-line and code with unconditional branches in it with modern processors. In fact, there's very little measurable difference. If you're looking for something to blame hurd performance on I'd suggest the entire design of Mach, not inline asm vs procedure calls. Tossing a few context switches into calls is a lot more expensive. hpa That's not where the bulk of the penalty of a function call comes in (and it's a call/return, not an unconditional branch.) The penalty comes in because of the additional need to obey the calling convention, and from the icache discontinuity. call/return is two unconditional branches and a push and a pop (is that right?), which is I think what CD means, i.e. in terms of branch prediction. The push/pop is a hit on old CPUs, donno about 386. You're right though. The big hit is you can't lose the pushes to set up the args for a separately assembled function, or the frame drop that follows it. Not to mention that certain things simply cannot be done that way. Don't tell me that. Then I can't use my subroutine-threaded Forth variant, in which + is a subroutine call. ;o) Anyway, yes it's a performance hit to not inline asms. Is it worth the bletchery? It's worth asking that once in a while. I've looked at set_bit both ways. Now I'm curious how it does as straight C. Rick Hohensee - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why Plan 9 C compilers don't have asm()
On Tue, Jul 03, 2001 at 11:37:28PM -0400, Rick Hohensee wrote: That's with the GNU tools, without asm(), and without proper declaration of printf, as is my tendency. I don't actually return an int either, do I? LAAETTR. Under ISO C rules, this is illegal, since you must have a proper prototype in scope when calling variable argument functions. In fact, I have worked on several GCC ports, where the compiler uses a different calling sequence for variable argument functions than it does for normal functions. For example, on the Mips, if the first argument is floating point and the number of arguments is not variable, it is passed in a FP register, instead of an integer register. For variable argument functions, everything is passed in the integer registers. I didn't know that, but... You seem to be saying the use of assumptions about args passing is non-standard. I know. It's more standard than GNU extensions to C though, C_labels_in_asms in particular, and even in your examples it appears that the particular function abusing these tenets will know what it can expect from a particular compiler, since it knows what it's arguments are. It can't know what it can expect from any compiler. This perhaps is where #ifdef comes in, or similar. Well, it's not more standard than GNU, but the differences would be less detailed in the case of just dealing with various args passing schemes, and there may be some compiler-to-compiler overlap, where there won't be any with stuff like C_labels_in_asms. It's illegal to not declare main() as int. I don't know of a unix that actually passes anything but a byte to the calling process. I got flamed mightily for this in comp.unix.programmer until people ran some checks on thier big Real Unix(TM) boxes of various types. Linux won't pass void either, you have to get a 0 at least. Compliance is subjective. It's easier when things make sense. Rick Hohensee www.clienux.com -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why Plan 9 C compilers don't have asm()
Now, you could probably argue that instead of inline asms we should have more flexibility in doing a per-callee calling convention. That would be good too, no question about it. Linus Today's flamebait has been postponed. Happy July 4th. Peace. Rick Hohensee www.clienux.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Why Plan 9 C compilers don't have asm("")
Because it's messy and unnecessary. Break this into asmlinkbuild,
asmlink.c, asmlink.h and asmlink.S, chmod +x asmlinkbuild, run it, and
behold a 6.
__
#..
# asmlinkbuild
gcc -c asmlink.S
gcc -o asmlinked asmlink.c asmlink.o
asmlinked
cat asmlinkbuild asmlink.S asmlink.c > asmlink.post
/* ***
asmlink.S
int bla (int ha, int hahaha, int uh) ;
That does...
push uh
push hahaha
push ha
*/
.globl bla
bla:
add 4(%esp), %eax
add 8(%esp), %eax
add 12(%esp), %eax
ret
/* asmlink.c */
#include "asmlink.h"
int main () {
printf("%d\n", bla(1, 2 , 3 ) ) ;
}
_
That's with the GNU tools, without asm(), and without proper declaration
of printf, as is my tendency. I don't actually return an int either, do I?
LAAETTR.
In other words, if you know the push sequence of your C compiler's
function calls, you don't need asm("");. x86 Gcc is "push last declared
first, return in EAX". Plan 9 guys, not surprisingly, seem to prefer to
keep C as C, and asm as asm. I encountered this while trying to build
Linux 1.2.13 with current GNU tools. It breaks on changes in GNU C
asm()'s. Rather a silly thing to break on, eh?
I don't think this is much less clear than the : "=r" $0; stuff, if at
all. This thing didn't take as long to code as it did to construct this
post. Perhaps the C-labels-in-asms optimizes better. I doubt if it's by
much, or if it's worth it.
Oops. I didn't include asmlink.h in the above, except as a comment
in asmlink.S. Here it is by itself...
/* asmlink.h*/
int bla (int ha, int hahaha, int uh) ;
Another easy win from Plan 9 that's related to this but that is not in
evidence here is that this thing on Plan 9 could build asmlinkbuild for
itself on the fly based on #pragma's in the headers that simply state what
library they are the header for. This to me is so obviously an improvement
to the usual state of affairs, an ornate system of dead-ends, as to be
depressing. The guys that wrote UNIX don't do such things to themselves
anymore.
Rick Hohensee
:; cLIeNUX /dev/tty11 11:00:14 /
:;d
ABOUTLGPL boot device log subroutine
ABOUT.Linux Linuxcommand floppy mounts suite
GPL README configureguestownertemp
H3nixRIGHTS dev help source
:; cLIeNUX /dev/tty11 22:44:25 /
:;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Why Plan 9 C compilers don't have asm()
Because it's messy and unnecessary. Break this into asmlinkbuild,
asmlink.c, asmlink.h and asmlink.S, chmod +x asmlinkbuild, run it, and
behold a 6.
__
#..
# asmlinkbuild
gcc -c asmlink.S
gcc -o asmlinked asmlink.c asmlink.o
asmlinked
cat asmlinkbuild asmlink.S asmlink.c asmlink.post
/* ***
asmlink.S
int bla (int ha, int hahaha, int uh) ;
That does...
push uh
push hahaha
push ha
*/
.globl bla
bla:
add 4(%esp), %eax
add 8(%esp), %eax
add 12(%esp), %eax
ret
/* asmlink.c */
#include asmlink.h
int main () {
printf(%d\n, bla(1, 2 , 3 ) ) ;
}
_
That's with the GNU tools, without asm(), and without proper declaration
of printf, as is my tendency. I don't actually return an int either, do I?
LAAETTR.
In other words, if you know the push sequence of your C compiler's
function calls, you don't need asm();. x86 Gcc is push last declared
first, return in EAX. Plan 9 guys, not surprisingly, seem to prefer to
keep C as C, and asm as asm. I encountered this while trying to build
Linux 1.2.13 with current GNU tools. It breaks on changes in GNU C
asm()'s. Rather a silly thing to break on, eh?
I don't think this is much less clear than the : =r $0; stuff, if at
all. This thing didn't take as long to code as it did to construct this
post. Perhaps the C-labels-in-asms optimizes better. I doubt if it's by
much, or if it's worth it.
Oops. I didn't include asmlink.h in the above, except as a comment
in asmlink.S. Here it is by itself...
/* asmlink.h*/
int bla (int ha, int hahaha, int uh) ;
Another easy win from Plan 9 that's related to this but that is not in
evidence here is that this thing on Plan 9 could build asmlinkbuild for
itself on the fly based on #pragma's in the headers that simply state what
library they are the header for. This to me is so obviously an improvement
to the usual state of affairs, an ornate system of dead-ends, as to be
depressing. The guys that wrote UNIX don't do such things to themselves
anymore.
Rick Hohensee
:; cLIeNUX /dev/tty11 11:00:14 /
:;d
ABOUTLGPL boot device log subroutine
ABOUT.Linux Linuxcommand floppy mounts suite
GPL README configureguestownertemp
H3nixRIGHTS dev help source
:; cLIeNUX /dev/tty11 22:44:25 /
:;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Uncle Sam Wants YOU!
> > Pardon me, but what does this have to do with Linux or the Linux Kernel?!?! > Post this on the usenet under advocacy, but please don't litter up the > kernel listserver with this. What this has to do with Linux is that throughout the whole process Microsoft has been putting Linux in the news, on the front page, and now is the opportunity for the people who have been damaged by Microsoft, the people that have very good reasons to be massively dissatisfied with Windows, a set of people that the readers of this list exemplifies, have an opportunity to speak on the matter in a helpful and substantive way that will be of more benefit than any work directly on Linux itself can be, to the computer world generally and to Linux. Rick Hohensee :; cLIeNUX /dev/tty3 11:09:49 / :;d ABOUTLinuxboot floppy mounts temp ABOUT.Linux NetBSD command guestowner Cintpos README configurehelp source GPL RIGHTS dev incoming subroutine LGPL VVT.tar device log suite :; cLIeNUX /dev/tty3 11:29:59 / :; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Uncle Sam Wants YOU!
Pardon me, but what does this have to do with Linux or the Linux Kernel?!?! Post this on the usenet under advocacy, but please don't litter up the kernel listserver with this. What this has to do with Linux is that throughout the whole process Microsoft has been putting Linux in the news, on the front page, and now is the opportunity for the people who have been damaged by Microsoft, the people that have very good reasons to be massively dissatisfied with Windows, a set of people that the readers of this list exemplifies, have an opportunity to speak on the matter in a helpful and substantive way that will be of more benefit than any work directly on Linux itself can be, to the computer world generally and to Linux. Rick Hohensee :; cLIeNUX /dev/tty3 11:09:49 / :;d ABOUTLinuxboot floppy mounts temp ABOUT.Linux NetBSD command guestowner Cintpos README configurehelp source GPL RIGHTS dev incoming subroutine LGPL VVT.tar device log suite :; cLIeNUX /dev/tty3 11:29:59 / :; - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Uncle Sam Wants YOU!
The two branches of the USA that pertain have now confirmed that Microsoft is a problem requiring an externally asserted solution, but the judicial branch has rejected the specific solution proposed by the executive branch. Three other proposed remedies are mentioned in the Washington Post today. One involves allowing developers access to Microsoft sourcecode equally. One involves allowing computer vendors to configure the Microsoft software as they see fit. The third involves unbundling software from the OS. Gates had stated, correctly, that the split of the company proposed by DOJ did not reflect any understanding of the software business. Looking at the three subsequent proposals, it appears to me that this problem is still searching for a solution. These three recent superficialities also do not appear to be the ideas of people who know how these things work. Meanwhile, Microsoft whole-heartedly engages in a depraved attack on the copyright rights of individuals, making it delightfully clear that the problem remains unsolved, and that Microsoft's general degradation of the computer world continues unabated. HELLO??? ANY GEEKS IN HERE? ANY OF YOU TURKEYS GOOD WITH PROBLEM-SOLVING? My hastily concocted proposed solution remains at... ftp://ftp.gwdg.de/pub/linux/install/clienux/interim/amicus_curae WHERE'S YOURS? Rick Hohensee www.cLIeNUX.com Who do you want to piss off today? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Uncle Sam Wants YOU!
The two branches of the USA that pertain have now confirmed that Microsoft is a problem requiring an externally asserted solution, but the judicial branch has rejected the specific solution proposed by the executive branch. Three other proposed remedies are mentioned in the Washington Post today. One involves allowing developers access to Microsoft sourcecode equally. One involves allowing computer vendors to configure the Microsoft software as they see fit. The third involves unbundling software from the OS. Gates had stated, correctly, that the split of the company proposed by DOJ did not reflect any understanding of the software business. Looking at the three subsequent proposals, it appears to me that this problem is still searching for a solution. These three recent superficialities also do not appear to be the ideas of people who know how these things work. Meanwhile, Microsoft whole-heartedly engages in a depraved attack on the copyright rights of individuals, making it delightfully clear that the problem remains unsolved, and that Microsoft's general degradation of the computer world continues unabated. HELLO??? ANY GEEKS IN HERE? ANY OF YOU TURKEYS GOOD WITH PROBLEM-SOLVING? My hastily concocted proposed solution remains at... ftp://ftp.gwdg.de/pub/linux/install/clienux/interim/amicus_curae WHERE'S YOURS? Rick Hohensee www.cLIeNUX.com Who do you want to piss off today? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The Joy of Forking
> > Rick Hohensee <[EMAIL PROTECTED]> said: > > 2.4.5 is 26 meg now. It's time to consider forking the kernel. Alan has > > already stuck his tippy-toe is that pool, and his toe is fine. > > Stop that nonsense. Alan Cox has _not_ forked anything, neither has Dave > Miller, or any of the arch maintainers. Alan has said several times that he > will sync up with Linus, and he still stages patches upwards. Alan doesn't > like the "all shall be devfs" ukase (and neither do I, BTW), and will > maintain non-devfs systems for the time being. > > I do see the merit of some kind of devfs, but there still is a lot of stuff > that needs a more reasonable solution, so no thanks for now. I've had quite a good two rants lately and will be happy to get on to other things for now. My point is to think of devfs and dozens of other things in the context of more than one Linux. Just a thought. Rick Hohensee www.clienux.com > -- > Horst von Brand [EMAIL PROTECTED] > Casilla 9G, Vin~a del Mar, Chile +56 32 672616 > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The Joy of Forking
> > On Sun, 24 Jun 2001, Rick Hohensee wrote: > >2.4.5 is 26 meg now. It's time to consider forking the kernel. Alan has > >already stuck his tippy-toe is that pool, and his toe is fine. > > > > forget POSIX > > The standards that matter are de-facto standards. Linux is the > > standard. Congratulations. Take your seat in the chair for > > First Violin. > > NO. I port too many programs both ways. I need POSIX compliancy as much as > is possible. That way the programs will compile and go among Linux, UNICOS, > IRIX, Solaris, AIX, and sometimes HP-UX. That's fine for things unix does well. Realtime is one counterexample. > > > rtlinux by default > > no SMP > > SMP doesn't scale. If this fork comes, the smart maintainer > > will take the non-SMP fork. > > Depends on platform and bus. From reports, it seems to scale just fine on > non-intel systems. Big expensive systems. Non-desktop systems. Non-end-user systems. And clustering will eat its lunch eventually anyway. > > > x86 only (and similar, e.g. Crusoe) > > Again, Linux is the only system that CAN run on anything from PDA thorough > supercomputer clusters. > NetBSD claims 24 platforms. Forths run on everything you've never heard of below a PDA. > > mimimal VM cacheing > > So you can red-switch the box without journalling with > > reasonable damage, which for an end-user is a file or two. > > Having done a lot of very wrong things with Linux, I'm > > impressed that ext2 doesn't self-destruct under abuse. > > Not if you want some speed out of it. Again, throughput is a server thing. > > > in-kernel interpreter > > I have one working. It's fun. > > VIRUSES, VIRUSES, and MORE VIRUS entry points. Assuming you mean both > translator and execution at the same time. And assembler. This is called get your hands greasy. Fun. Your box. Not the admin's box. > > > EOL is CR > > The one thing Dos got right and unix got wrong. Also, in my > > 2-month experience in a cube on a LAN, the most annoying thing > > about trying to be a Linux end-user in a Dos shop. Printers > > are CRLF, fer crissakes. > > This is not a difficult mod, but it's a lot of little changes > > throughout a box. Things that look for EOLs are the part that > > has to be fixed by hand, and can be inclusive of CRLF and LF. > > I've used both. They are equivalent. Live with it. > We disagree, but I wont rant about the phone company breaking a perfectly good telegraphy protocol called ASCII. > > Plan 9-style header files structure > > Plan 9's most amazing stuff to me is the subtle refinements, > > like sane header files. Sane C header files, _oh_ _my_ _God_. > > As long as source code portability is maintained. Dennis Ritchie, who signs the checks for the people that wrote Plan 9, said an interesting thing about portability. He said "good code is portable code." I infer from that, and from the Plan 9 sources, and from the design of unix and the two-character commands in /bin/, that he relates good very strongly with simple. Not slavish adherance to standards. Plan 9 C isn't ANSI, for example. The unix portability suite is called "ape". > > > excellent localizability > > e.g. kernel error strings mapped to a file, or an #include > > that can be language-specific. My DSFH stuff also. > > This is quite reasonable. Actually, unless you are referring to Kernel internal > error codes, it's already done with perror. > > > > >What about GUI's, and "desktops" and such? They're nice. They are > >secondary, however. The free unix world doesn't often enough make the > >point that GUI's are much more important when the underlying OS sucks, > >which it doesn't in Linux. > > If you only use a compute/disk server. Otherwise you are saying "no desktop > publishing, word processing, or image analysis". > > Are you still using DOS only? > I haven't started X in about a year. I read pdf's as jpegs, I have Xaos running in SVGA, and so on. Not-unix != Dos . I don't dislike X particularly, but I live in what I ship, and for maintenance I can't keep up with console, considering that I'm doing a bit more than just bundling things up. > >In short, an open source OS for end-users should be very serious about > >simplicity, and not just pay lip-service to it. There is evidence of the > >value of this in the
Re: The Joy of Forking
On Sun, 24 Jun 2001, Rick Hohensee wrote: 2.4.5 is 26 meg now. It's time to consider forking the kernel. Alan has already stuck his tippy-toe is that pool, and his toe is fine. forget POSIX The standards that matter are de-facto standards. Linux is the standard. Congratulations. Take your seat in the chair for First Violin. NO. I port too many programs both ways. I need POSIX compliancy as much as is possible. That way the programs will compile and go among Linux, UNICOS, IRIX, Solaris, AIX, and sometimes HP-UX. That's fine for things unix does well. Realtime is one counterexample. rtlinux by default no SMP SMP doesn't scale. If this fork comes, the smart maintainer will take the non-SMP fork. Depends on platform and bus. From reports, it seems to scale just fine on non-intel systems. Big expensive systems. Non-desktop systems. Non-end-user systems. And clustering will eat its lunch eventually anyway. x86 only (and similar, e.g. Crusoe) Again, Linux is the only system that CAN run on anything from PDA thorough supercomputer clusters. NetBSD claims 24 platforms. Forths run on everything you've never heard of below a PDA. mimimal VM cacheing So you can red-switch the box without journalling with reasonable damage, which for an end-user is a file or two. Having done a lot of very wrong things with Linux, I'm impressed that ext2 doesn't self-destruct under abuse. Not if you want some speed out of it. Again, throughput is a server thing. in-kernel interpreter I have one working. It's fun. VIRUSES, VIRUSES, and MORE VIRUS entry points. Assuming you mean both translator and execution at the same time. And assembler. This is called get your hands greasy. Fun. Your box. Not the admin's box. EOL is CRLF The one thing Dos got right and unix got wrong. Also, in my 2-month experience in a cube on a LAN, the most annoying thing about trying to be a Linux end-user in a Dos shop. Printers are CRLF, fer crissakes. This is not a difficult mod, but it's a lot of little changes throughout a box. Things that look for EOLs are the part that has to be fixed by hand, and can be inclusive of CRLF and LF. I've used both. They are equivalent. Live with it. We disagree, but I wont rant about the phone company breaking a perfectly good telegraphy protocol called ASCII. Plan 9-style header files structure Plan 9's most amazing stuff to me is the subtle refinements, like sane header files. Sane C header files, _oh_ _my_ _God_. As long as source code portability is maintained. Dennis Ritchie, who signs the checks for the people that wrote Plan 9, said an interesting thing about portability. He said good code is portable code. I infer from that, and from the Plan 9 sources, and from the design of unix and the two-character commands in /bin/, that he relates good very strongly with simple. Not slavish adherance to standards. Plan 9 C isn't ANSI, for example. The unix portability suite is called ape. excellent localizability e.g. kernel error strings mapped to a file, or an #include that can be language-specific. My DSFH stuff also. This is quite reasonable. Actually, unless you are referring to Kernel internal error codes, it's already done with perror. What about GUI's, and desktops and such? They're nice. They are secondary, however. The free unix world doesn't often enough make the point that GUI's are much more important when the underlying OS sucks, which it doesn't in Linux. If you only use a compute/disk server. Otherwise you are saying no desktop publishing, word processing, or image analysis. Are you still using DOS only? I haven't started X in about a year. I read pdf's as jpegs, I have Xaos running in SVGA, and so on. Not-unix != Dos . I don't dislike X particularly, but I live in what I ship, and for maintenance I can't keep up with console, considering that I'm doing a bit more than just bundling things up. In short, an open source OS for end-users should be very serious about simplicity, and not just pay lip-service to it. There is evidence of the value of this in the marketplace. What doesn't exist is an OS where simplicity is systemic. This is why end-user issues pertain to the kernel at all. This is how open source should be. Simple, or at least clear, through and through. Linux has lost a lot of simplicity since I got into it in '96, and that is a loss. For the most part, the base Linux appears simple to the user. There are no Which distro appears simple to the user? desktops to worry about. Desktops are an application, not part of Linux at all It is becoming better
Re: The Joy of Forking
Rick Hohensee [EMAIL PROTECTED] said: 2.4.5 is 26 meg now. It's time to consider forking the kernel. Alan has already stuck his tippy-toe is that pool, and his toe is fine. Stop that nonsense. Alan Cox has _not_ forked anything, neither has Dave Miller, or any of the arch maintainers. Alan has said several times that he will sync up with Linus, and he still stages patches upwards. Alan doesn't like the all shall be devfs ukase (and neither do I, BTW), and will maintain non-devfs systems for the time being. I do see the merit of some kind of devfs, but there still is a lot of stuff that needs a more reasonable solution, so no thanks for now. I've had quite a good two rants lately and will be happy to get on to other things for now. My point is to think of devfs and dozens of other things in the context of more than one Linux. Just a thought. Rick Hohensee www.clienux.com -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
The Joy of Forking
2.4.5 is 26 meg now. It's time to consider forking the kernel. Alan has already stuck his tippy-toe is that pool, and his toe is fine. The "thou shalt not fork" commandment made sense at one point, when free unix was a lost tribe wandering hungry in the desert. When you have a project with several million users that has a scope that simply doesn't scale, it doesn't. Forking should be done responsibly, and with great joy. As in nature, software success breeds diversity. Linux should diversify. This is cause for celebration, ceremony, throwing of bouquets and so on. I have done a few trivial things that people with rather shallow ideas of what unix is about have excoriated as "NOT UNIX!". So far that's been absurd, but my stuff is getting more intrusive. Linux is far more interesting to me for it's general usefulness and openness, which are inextricably related, than for it's unixness, although unix is certainly beautiful. Alan was going to file for divorce over dev_t. Isn't is funny how estranged couples so often are so much alike? dev_t is crucial, of course, but it's not the biggest geological fault in the kernel. SMP is. I have dropped hints about this before. An SMP system is more fundamentally different than UP than a 386 is different than other big microprocessors. As I mentioned that Steve Ballmer mentioned, Linux isn't getting any traction on the client, the end-user desktop box. That's a huge and poorly served market, so there are lots of tragically shallow ideas of how to approach it. A few variations on the Linux theme are in order, that preserve unixness, openness, but that don't have pretenses of being Big UNIX(TM). For a client-use Linux kernel, I suggest, and will be and have been persuing, features and non-features such as... forget POSIX The standards that matter are de-facto standards. Linux is the standard. Congratulations. Take your seat in the chair for First Violin. rtlinux by default no SMP SMP doesn't scale. If this fork comes, the smart maintainer will take the non-SMP fork. x86 only (and similar, e.g. Crusoe) mimimal VM cacheing So you can red-switch the box without journalling with reasonable damage, which for an end-user is a file or two. Having done a lot of very wrong things with Linux, I'm impressed that ext2 doesn't self-destruct under abuse. in-kernel interpreter I have one working. It's fun. EOL is CR The one thing Dos got right and unix got wrong. Also, in my 2-month experience in a cube on a LAN, the most annoying thing about trying to be a Linux end-user in a Dos shop. Printers are CRLF, fer crissakes. This is not a difficult mod, but it's a lot of little changes throughout a box. Things that look for EOLs are the part that has to be fixed by hand, and can be inclusive of CRLF and LF. Plan 9-style header files structure Plan 9's most amazing stuff to me is the subtle refinements, like sane header files. Sane C header files, _oh_ _my_ _God_. excellent localizability e.g. kernel error strings mapped to a file, or an #include that can be language-specific. My DSFH stuff also. What about GUI's, and "desktops" and such? They're nice. They are secondary, however. The free unix world doesn't often enough make the point that GUI's are much more important when the underlying OS sucks, which it doesn't in Linux. In short, an open source OS for end-users should be very serious about simplicity, and not just pay lip-service to it. There is evidence of the value of this in the marketplace. What doesn't exist is an OS where simplicity is systemic. This is why end-user issues pertain to the kernel at all. This is how open source should be. Simple, or at least clear, through and through. Linux has lost a lot of simplicity since I got into it in '96, and that is a loss. Rick Hohensee www.clienux.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
The Joy of Forking
2.4.5 is 26 meg now. It's time to consider forking the kernel. Alan has already stuck his tippy-toe is that pool, and his toe is fine. The thou shalt not fork commandment made sense at one point, when free unix was a lost tribe wandering hungry in the desert. When you have a project with several million users that has a scope that simply doesn't scale, it doesn't. Forking should be done responsibly, and with great joy. As in nature, software success breeds diversity. Linux should diversify. This is cause for celebration, ceremony, throwing of bouquets and so on. I have done a few trivial things that people with rather shallow ideas of what unix is about have excoriated as NOT UNIX!. So far that's been absurd, but my stuff is getting more intrusive. Linux is far more interesting to me for it's general usefulness and openness, which are inextricably related, than for it's unixness, although unix is certainly beautiful. Alan was going to file for divorce over dev_t. Isn't is funny how estranged couples so often are so much alike? dev_t is crucial, of course, but it's not the biggest geological fault in the kernel. SMP is. I have dropped hints about this before. An SMP system is more fundamentally different than UP than a 386 is different than other big microprocessors. As I mentioned that Steve Ballmer mentioned, Linux isn't getting any traction on the client, the end-user desktop box. That's a huge and poorly served market, so there are lots of tragically shallow ideas of how to approach it. A few variations on the Linux theme are in order, that preserve unixness, openness, but that don't have pretenses of being Big UNIX(TM). For a client-use Linux kernel, I suggest, and will be and have been persuing, features and non-features such as... forget POSIX The standards that matter are de-facto standards. Linux is the standard. Congratulations. Take your seat in the chair for First Violin. rtlinux by default no SMP SMP doesn't scale. If this fork comes, the smart maintainer will take the non-SMP fork. x86 only (and similar, e.g. Crusoe) mimimal VM cacheing So you can red-switch the box without journalling with reasonable damage, which for an end-user is a file or two. Having done a lot of very wrong things with Linux, I'm impressed that ext2 doesn't self-destruct under abuse. in-kernel interpreter I have one working. It's fun. EOL is CRLF The one thing Dos got right and unix got wrong. Also, in my 2-month experience in a cube on a LAN, the most annoying thing about trying to be a Linux end-user in a Dos shop. Printers are CRLF, fer crissakes. This is not a difficult mod, but it's a lot of little changes throughout a box. Things that look for EOLs are the part that has to be fixed by hand, and can be inclusive of CRLF and LF. Plan 9-style header files structure Plan 9's most amazing stuff to me is the subtle refinements, like sane header files. Sane C header files, _oh_ _my_ _God_. excellent localizability e.g. kernel error strings mapped to a file, or an #include that can be language-specific. My DSFH stuff also. What about GUI's, and desktops and such? They're nice. They are secondary, however. The free unix world doesn't often enough make the point that GUI's are much more important when the underlying OS sucks, which it doesn't in Linux. In short, an open source OS for end-users should be very serious about simplicity, and not just pay lip-service to it. There is evidence of the value of this in the marketplace. What doesn't exist is an OS where simplicity is systemic. This is why end-user issues pertain to the kernel at all. This is how open source should be. Simple, or at least clear, through and through. Linux has lost a lot of simplicity since I got into it in '96, and that is a loss. Rick Hohensee www.clienux.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mktime in include/linux
> > At 1:43 PM +0200 2001-06-22, Erik Mouw wrote: > >On Thu, Jun 21, 2001 at 10:30:40PM -0400, Rick Hohensee wrote: > >> Why does Linux have a mktime routine fully coded in linux/time.h that > >> conflicts directly with the ANSI C standard library routine of the same > >> name? It breaks a couple things against libc5, including gcc 3.0. OK, you > >> don't care about libc5. It's still pretty weird. Wierd? Weird. > > > >This has been brought up many times on this list: you are not supposed > >to include kernel headers in userland. > > That's not the problem, I think. Most of time.h, including the > definition of mktime, is #ifdef __KERNEL__, so it shouldn't be > breaking anything in userland even if you do include it. And you > might, in order to obtain the interface definition of struct > timespec. What's weird is: why is __KERNEL__ getting #defined in > Rick's userland? > > There can't, of course, be any blanket prohibition against using > kernel headers in userland. Think about ioctl.h, for example. Sounds like a clue. Thanks. Rick > -- > /Jonathan Lundell. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mktime in include/linux
At 1:43 PM +0200 2001-06-22, Erik Mouw wrote: On Thu, Jun 21, 2001 at 10:30:40PM -0400, Rick Hohensee wrote: Why does Linux have a mktime routine fully coded in linux/time.h that conflicts directly with the ANSI C standard library routine of the same name? It breaks a couple things against libc5, including gcc 3.0. OK, you don't care about libc5. It's still pretty weird. Wierd? Weird. This has been brought up many times on this list: you are not supposed to include kernel headers in userland. That's not the problem, I think. Most of time.h, including the definition of mktime, is #ifdef __KERNEL__, so it shouldn't be breaking anything in userland even if you do include it. And you might, in order to obtain the interface definition of struct timespec. What's weird is: why is __KERNEL__ getting #defined in Rick's userland? There can't, of course, be any blanket prohibition against using kernel headers in userland. Think about ioctl.h, for example. Sounds like a clue. Thanks. Rick -- /Jonathan Lundell. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Controversy over dynamic linking -- how to end the panic
[EMAIL PROTECTED] (Andrew Pimlott) >I agree entirely that Linus, as creator of the license, is >privileged with respect to interpretation of the license. I Richard Stallman is the creator of the license. It's his greatest work. Linus is in no way priviledged as to interpretation of it, other than tolerance on the part of the parties that own the copyright to the license. The GPL is about "the program". As far as I'm concerned, modules are the kernel, "the program". The way to stem any panic that may exist, if you want to allow binary-only modules (which sucks*, but whatever), is to LGPL or "KGPL" the kernel. What is being allowed now is in violation of the GPL. Rick Hohensee www.clienux.com *How 'bout a nice binary-only Forth running the kernel? Metacompiling kernel routines into the Forth dictionary and such. Sound creepy? Good. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
mktime in include/linux
Why does Linux have a mktime routine fully coded in linux/time.h that conflicts directly with the ANSI C standard library routine of the same name? It breaks a couple things against libc5, including gcc 3.0. OK, you don't care about libc5. It's still pretty weird. Wierd? Weird. Rick Hohensee www.cLIeNUX.com :;d -d */ Cintpos/ boot/device/ incoming/owner/ temp/ Debian/ command/ floppy/ log/ source/ Linux/ configure/ guest/ lost+found/ subroutine/ NetBSD/ dev/ help/mounts/ suite/ :; cLIeNUX /dev/tty12 22:00:52 / :; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
mktime in include/linux
Why does Linux have a mktime routine fully coded in linux/time.h that conflicts directly with the ANSI C standard library routine of the same name? It breaks a couple things against libc5, including gcc 3.0. OK, you don't care about libc5. It's still pretty weird. Wierd? Weird. Rick Hohensee www.cLIeNUX.com :;d -d */ Cintpos/ boot/device/ incoming/owner/ temp/ Debian/ command/ floppy/ log/ source/ Linux/ configure/ guest/ lost+found/ subroutine/ NetBSD/ dev/ help/mounts/ suite/ :; cLIeNUX /dev/tty12 22:00:52 / :; - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Controversy over dynamic linking -- how to end the panic
[EMAIL PROTECTED] (Andrew Pimlott) I agree entirely that Linus, as creator of the license, is privileged with respect to interpretation of the license. I Richard Stallman is the creator of the license. It's his greatest work. Linus is in no way priviledged as to interpretation of it, other than tolerance on the part of the parties that own the copyright to the license. The GPL is about the program. As far as I'm concerned, modules are the kernel, the program. The way to stem any panic that may exist, if you want to allow binary-only modules (which sucks*, but whatever), is to LGPL or KGPL the kernel. What is being allowed now is in violation of the GPL. Rick Hohensee www.clienux.com *How 'bout a nice binary-only Forth running the kernel? Metacompiling kernel routines into the Forth dictionary and such. Sound creepy? Good. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gnu asm help...
The C-names-in-asms stuff is explained in (g?)as.info. The explanation is a bit strained, but after the third or fourth read it becomes fairly sensible. Rick Hohensee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gnu asm help...
The C-names-in-asms stuff is explained in (g?)as.info. The explanation is a bit strained, but after the third or fourth read it becomes fairly sensible. Rick Hohensee - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Task Switching in Linux
Jaswinder Singh wrote: > > In Linux , If we assume that there are only 2 tasks A and B and both are > equal , this is correct or not :- > > TASK A -> schedule -> switch_to -> TASK B -> schedule -> switch_to -> > schedule -> switch_to -> TASK A. > If you mean "->" as "specifically calls" then that looks like cooperative multi-tasking, which is what kernel threads AND the Linux userland scheduler do. If an in-kernel thread doesn't call schedule, it keeps the CPU. See the H3rL stuff in ftp://linux01.gwdg.de/pub/cLIeNUX/interim Rick Hohensee :; cLIeNUX /dev/tty11 21:00:45 / :;d -d */ Cintpos/ boot/device/ incoming/owner/ temp/ Debian/ command/ floppy/ log/ source/ Linux/ configure/ guest/ lost+found/ subroutine/ NetBSD/ dev/ help/mounts/ suite/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Task Switching in Linux
Jaswinder Singh wrote: In Linux , If we assume that there are only 2 tasks A and B and both are equal , this is correct or not :- TASK A - schedule - switch_to - TASK B - schedule - switch_to - schedule - switch_to - TASK A. If you mean - as specifically calls then that looks like cooperative multi-tasking, which is what kernel threads AND the Linux userland scheduler do. If an in-kernel thread doesn't call schedule, it keeps the CPU. See the H3rL stuff in ftp://linux01.gwdg.de/pub/cLIeNUX/interim Rick Hohensee :; cLIeNUX /dev/tty11 21:00:45 / :;d -d */ Cintpos/ boot/device/ incoming/owner/ temp/ Debian/ command/ floppy/ log/ source/ Linux/ configure/ guest/ lost+found/ subroutine/ NetBSD/ dev/ help/mounts/ suite/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: Getting out of hand?
Torvalds sez >On Mon, 14 May 2001, Alan Cox wrote: >> >> Except that Linus wont hand out major numbers, which means I can't even boot >> simply off such a device. I bet the vendors in question dont think the sun >> shines out of linus backside any more. > >Actually, it does. It's just that some people have gotten so blinded by my >a** that they can no longer see it any more ;) > >The problem I have is that there are lots of _good_ solutions, but they >all imply a bit more work than the bad ones. > >What does that result in? Everybody continues to use the simple old setup, >which required no thought at all, but that is a pain to maintain. > >For example, the only thing you need in order to boot is to have a nice >clean "disk" major number. That's it. Nothing fancy, nothing more. To what extent do the code of the various drivers reflect that? i.e. is there some code that is common to all block devices, and that is used by code that is common to all disk devices, that further is used by all drivers pretending to be IDE devices, which is further used by all code pretending to be EIDE devices, etc. ? If you look at majors, say, as a binary tree which you walk in accordance with the bits in the major, can drivers nest like that? I've wondered about that for a long time for various reasons. Rick Hohensee www.clienux.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dget()
and the Linux source crossreferencing site at http://lxr.linux.no/ is awesome. Rick Hohensee www.clienux.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dget()
and the Linux source crossreferencing site at http://lxr.linux.no/ is awesome. Rick Hohensee www.clienux.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: Getting out of hand?
Torvalds sez On Mon, 14 May 2001, Alan Cox wrote: Except that Linus wont hand out major numbers, which means I can't even boot simply off such a device. I bet the vendors in question dont think the sun shines out of linus backside any more. Actually, it does. It's just that some people have gotten so blinded by my a** that they can no longer see it any more ;) The problem I have is that there are lots of _good_ solutions, but they all imply a bit more work than the bad ones. What does that result in? Everybody continues to use the simple old setup, which required no thought at all, but that is a pain to maintain. For example, the only thing you need in order to boot is to have a nice clean disk major number. That's it. Nothing fancy, nothing more. To what extent do the code of the various drivers reflect that? i.e. is there some code that is common to all block devices, and that is used by code that is common to all disk devices, that further is used by all drivers pretending to be IDE devices, which is further used by all code pretending to be EIDE devices, etc. ? If you look at majors, say, as a binary tree which you walk in accordance with the bits in the major, can drivers nest like that? I've wondered about that for a long time for various reasons. Rick Hohensee www.clienux.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: inserting a Forth-like language into the Linux kernel
read() of a tty from the kernel does behave as per the tty settings. I now have a kernel thread with stdin, out and err, FD's 0, 1 and 2, open and reading lines of typed input. The "interpreter" adds 0x30 (ASCII 0) to the return value from read and prints it, which means it occurs at the beginning of the next line. Here's what's sitting on my tty1 screen right now... . 1 1 1 1aaoeutasoeu aoeu oaeusntaoesutoaeut oeuoaeuo uoaeuoaeu h 6e 2 1 1 1 1ee 7ee 3 1onetu euaoeuaoeuoa eu aoeu ao eu ao eu aoeu aoeu ao eu aoe u aoe u te e e e e ;e e e e 9e e e e 9e e e 7ee 3 ... This should simplify hanging an interpreter off this simple little top loop. That is, userland H3sm was using cooked mode, so this is nice. This is the top loop code, which is x86 assembly and H3sm subroutines... . abort_H3sm: call buffer top_loop_of_H3sm: # stick a sleep in here. # Do not melt the CPU, do not slow down # the test cycle. call timespec call pdup call pplusc call pplusc call nanosleep call twopdrop call drop HANDOFF call zero # FD call read call literal .byte 4 .int 0x30 call plus call emit ELL(top_loop_of_H3sm) ... emit is similar to Forth EMIT. It is a one-byte write(). buffer and timespec put addresses on the H3sm pointer stack. nanosleep and read are H3sm stack-passing wrappers for the syscalls. HANDOFF is a macro for a stack-push-wrapped schedule(). It's a macro because I suspect I'm going to have to sprinkle it judiciously around H3sm. The nanosleep keeps my load average normal. Rick Hohensee www.clienux.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: inserting a Forth-like language into the Linux kernel
read() of a tty from the kernel does behave as per the tty settings. I now have a kernel thread with stdin, out and err, FD's 0, 1 and 2, open and reading lines of typed input. The interpreter adds 0x30 (ASCII 0) to the return value from read and prints it, which means it occurs at the beginning of the next line. Here's what's sitting on my tty1 screen right now... . 1 1 1 1aaoeutasoeu aoeu oaeusntaoesutoaeut oeuoaeuo uoaeuoaeu h 6e 2 1 1 1 1ee 7ee 3 1onetu euaoeuaoeuoa eu aoeu ao eu ao eu aoeu aoeu ao eu aoe u aoe u te e e e e ;e e e e 9e e e e 9e e e 7ee 3 ... This should simplify hanging an interpreter off this simple little top loop. That is, userland H3sm was using cooked mode, so this is nice. This is the top loop code, which is x86 assembly and H3sm subroutines... . abort_H3sm: call buffer top_loop_of_H3sm: # stick a sleep in here. # Do not melt the CPU, do not slow down # the test cycle. call timespec call pdup call pplusc call pplusc call nanosleep call twopdrop call drop HANDOFF call zero # FD call read call literal .byte 4 .int 0x30 call plus call emit ELL(top_loop_of_H3sm) ... emit is similar to Forth EMIT. It is a one-byte write(). buffer and timespec put addresses on the H3sm pointer stack. nanosleep and read are H3sm stack-passing wrappers for the syscalls. HANDOFF is a macro for a stack-push-wrapped schedule(). It's a macro because I suspect I'm going to have to sprinkle it judiciously around H3sm. The nanosleep keeps my load average normal. Rick Hohensee www.clienux.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: inserting a Forth-like language into the Linux kernel
> > > > > > > If someone knows of another example of interpreter-like behavior > > > > directly in a unix in-kernel thread I'd like to know about it. > > > > > > kdb > > > > > > > That runs in trap handlers doesn't it? I don't think it's a > > kernel daemon. > > and there's the hangman-in-kernel patch... > interpreter or daemon or app-in-system-space ??? Thanks, I'll look for that. Rick Hohensee > > ~Randy > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: inserting a Forth-like language into the Linux kernel
> > > I don't know about H1 S, but the ability to open a tty > > normally directly into kernelspace may prove popular, particularly > > with a Forth on that tty in that kernelspace. Persons with actual > > With anything other than Forth, LISP, and COBOL... yes. Nice little sensibility scale for kspamd-like things, Forth 1.0 Lisp 0.5 COBOL 0.0 > > > If someone knows of another example of interpreter-like behavior > > directly in a unix in-kernel thread I'd like to know about it. > > kdb > That runs in trap handlers doesn't it? I don't think it's a kernel daemon. Rick Hohensee www.clienux.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: inserting a Forth-like language into the Linux kernel
I don't know about H1 SM, but the ability to open a tty normally directly into kernelspace may prove popular, particularly with a Forth on that tty in that kernelspace. Persons with actual With anything other than Forth, LISP, and COBOL... yes. Nice little sensibility scale for kspamd-like things, Forth 1.0 Lisp 0.5 COBOL 0.0 If someone knows of another example of interpreter-like behavior directly in a unix in-kernel thread I'd like to know about it. kdb That runs in trap handlers doesn't it? I don't think it's a kernel daemon. Rick Hohensee www.clienux.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: inserting a Forth-like language into the Linux kernel
If someone knows of another example of interpreter-like behavior directly in a unix in-kernel thread I'd like to know about it. kdb That runs in trap handlers doesn't it? I don't think it's a kernel daemon. and there's the hangman-in-kernel patch... interpreter or daemon or app-in-system-space ??? Thanks, I'll look for that. Rick Hohensee ~Randy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: inserting a Forth-like language into the Linux kernel
kspamd/H3sm is now making continuous writes to tty1 from an in-kernel thread. It was locking on a write to /dev/console by init, so I made /dev/console a plain file. This is after hollowing out sys_syslog to be a null routine, and various other minor destruction. I am now typing at you on tty4 or so while the kernel itself sends an endless stream of d's to tty1. It will scroll-lock and un-scroll-lock, which is how I can tell it's not just a static screen of d's. I don't know about H1 S, but the ability to open a tty normally directly into kernelspace may prove popular, particularly with a Forth on that tty in that kernelspace. Persons with actual kernel clue may want to look at allowing /dev/console users and an in-kernel tty user to play nice. For my purposes I'll do without a real /dev/console and syslogging for now. Now I get to find out how many worlds of trouble I didn't foresee in _reading_ a tty from the kernel :o) If someone knows of another example of interpreter-like behavior directly in a unix in-kernel thread I'd like to know about it. Rick Hohensee www.clienux.com The userland H3sm is in ftp://ftp.gwdg.de/pub/linux/include/clienux/interim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: inserting a Forth-like language into the Linux kernel
In 2.4.0-test10, in my kspamd kernel-thread that's like a hollowed-out kswapd, I have x86 asm code like this... [enter from in-kernel init] [open 3 FDs on tty1] LOOP: pushf pusha call schedule popa popf [ here is some code to use the write syscall to send one byte to FD 1. A d, for example. ] jmp LOOP The d's get written until a syslog happens. If I do do_syslog(6,6,6); in the C kspamd wrapper code it's about like so... ddd dddINIT: entering runlevel 8 [more normal logging stuff, ext2 warnings and so on] If I don't do the do_syslog() the same thing happens somewhat earlier, i.e. on a from-the-kernel-itself syslog. Boot is normal. I can't shift_up vt1, which normally I can, but I can switch vt's, email you, etc. /proc/4/status for kspamd shows Name: kspamd State: R (running) Pid:4 PPid: 1 PIDs 1, 2 and 3 don't have any open FD's. My simplistic wrapper pegs CPU use at 1.0. Why don't my d's continue? Might this be easier to do in a 2.0 kernel? Rick Hohensee www.clienux.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: inserting a Forth-like language into the Linux kernel
In 2.4.0-test10, in my kspamd kernel-thread that's like a hollowed-out kswapd, I have x86 asm code like this... [enter from in-kernel init] [open 3 FDs on tty1] LOOP: pushf pusha call schedule popa popf [ here is some code to use the write syscall to send one byte to FD 1. A d, for example. ] jmp LOOP The d's get written until a syslog happens. If I do do_syslog(6,6,6); in the C kspamd wrapper code it's about like so... gobs of d'sddd dddINIT: entering runlevel 8 [more normal logging stuff, ext2 warnings and so on] If I don't do the do_syslog() the same thing happens somewhat earlier, i.e. on a from-the-kernel-itself syslog. Boot is normal. I can't shiftpg_up vt1, which normally I can, but I can switch vt's, email you, etc. /proc/4/status for kspamd shows Name: kspamd State: R (running) Pid:4 PPid: 1 PIDs 1, 2 and 3 don't have any open FD's. My simplistic wrapper pegs CPU use at 1.0. Why don't my d's continue? Might this be easier to do in a 2.0 kernel? Rick Hohensee www.clienux.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: inserting a Forth-like language into the Linux kernel
kspamd/H3sm is now making continuous writes to tty1 from an in-kernel thread. It was locking on a write to /dev/console by init, so I made /dev/console a plain file. This is after hollowing out sys_syslog to be a null routine, and various other minor destruction. I am now typing at you on tty4 or so while the kernel itself sends an endless stream of d's to tty1. It will scroll-lock and un-scroll-lock, which is how I can tell it's not just a static screen of d's. I don't know about H1 SM, but the ability to open a tty normally directly into kernelspace may prove popular, particularly with a Forth on that tty in that kernelspace. Persons with actual kernel clue may want to look at allowing /dev/console users and an in-kernel tty user to play nice. For my purposes I'll do without a real /dev/console and syslogging for now. Now I get to find out how many worlds of trouble I didn't foresee in _reading_ a tty from the kernel :o) If someone knows of another example of interpreter-like behavior directly in a unix in-kernel thread I'd like to know about it. Rick Hohensee www.clienux.com The userland H3sm is in ftp://ftp.gwdg.de/pub/linux/include/clienux/interim - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: inserting a Forth-like language into the Linux kernel
> I thought my mail client was doing "reply to all recipients". If it _was_ then this is redundant and I apologize. > > > On Tue, 1 May 2001, Rick Hohensee wrote: > > > (kspamd) is the Linux-side wrapper for H3sm > > C|N>K > > OK, you owe me a new keyboard. And thanks for new .sig. Oh, uh, sorry about that, Chief. > BTW, Rick, out of curiosity - how many Greencard Lawyers does it take > to upgrade the thing to full-blown H1 S? > I dono. How many you got? Rick Hohensee www.clienux.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: inserting a Forth-like language into the Linux kernel
I thought my mail client was doing reply to all recipients. If it _was_ then this is redundant and I apologize. On Tue, 1 May 2001, Rick Hohensee wrote: (kspamd) is the Linux-side wrapper for H3sm C|NK OK, you owe me a new keyboard. And thanks for new .sig. Oh, uh, sorry about that, Chief. BTW, Rick, out of curiosity - how many Greencard Lawyers does it take to upgrade the thing to full-blown H1 SM? I dono. How many you got? Rick Hohensee www.clienux.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
inserting a Forth-like language into the Linux kernel
all drop
ELL(top_loop_of_H3sm)
initialdp:
..
When the H3sm zombies the rest of Linux boots without it.
Here's some of the mm/vmscan.c in question
...
int kspamd(void *unused)
{
struct task_struct *tsk = current;
pg_data_t *pgdat;
tsk->session = 1;
tsk->pgrp = 1;
strcpy(tsk->comm, "kspamd");
/* sigfillset(>blocked);
current->flags |= PF_MEMALLOC;
*/
mainH3sm();
}
static int __init kswapd_init(void)
{
printk("Starting kswapd v1.8\n");
swap_setup();
kernel_thread(kswapd, NULL, CLONE_FS | CLONE_FILES |
CLONE_SIGNAL);
kernel_thread(kreclaimd, NULL, CLONE_FS | CLONE_FILES |
CLONE_SIGNAL);
kernel_thread(kspamd, NULL, CLONE_FS | CLONE_SIGNAL );
printk("Starting kspamd v0.00.00.00.01\n");
return 0;
}
That code is left over from some tests without H3sm that accepted the CPU
on every scheduling opportunity, resulting in the CPU use pegged at 1.0 or
more, but otherwise normal operation of Linux.
An ed script and some hand renaming suffixes all the labels in H3sm with
"H3sm" to eliminate name conflicts with Linux labels.
This is not how kdb works. That is an in-kernel debugger invoked on
breakpoint traps and so on. I don't know about kgdb, which is a wrapper
for the userland GNU symbolic debugger. gdb requires compiling the kernel
with debugging information inserted everywhere.
Rick Hohensee
www.clienux.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
inserting a Forth-like language into the Linux kernel
:
..
When the H3sm zombies the rest of Linux boots without it.
Here's some of the mm/vmscan.c in question
...
int kspamd(void *unused)
{
struct task_struct *tsk = current;
pg_data_t *pgdat;
tsk-session = 1;
tsk-pgrp = 1;
strcpy(tsk-comm, kspamd);
/* sigfillset(tsk-blocked);
current-flags |= PF_MEMALLOC;
*/
mainH3sm();
}
static int __init kswapd_init(void)
{
printk(Starting kswapd v1.8\n);
swap_setup();
kernel_thread(kswapd, NULL, CLONE_FS | CLONE_FILES |
CLONE_SIGNAL);
kernel_thread(kreclaimd, NULL, CLONE_FS | CLONE_FILES |
CLONE_SIGNAL);
kernel_thread(kspamd, NULL, CLONE_FS | CLONE_SIGNAL );
printk(Starting kspamd v0.00.00.00.01\n);
return 0;
}
That code is left over from some tests without H3sm that accepted the CPU
on every scheduling opportunity, resulting in the CPU use pegged at 1.0 or
more, but otherwise normal operation of Linux.
An ed script and some hand renaming suffixes all the labels in H3sm with
H3sm to eliminate name conflicts with Linux labels.
This is not how kdb works. That is an in-kernel debugger invoked on
breakpoint traps and so on. I don't know about kgdb, which is a wrapper
for the userland GNU symbolic debugger. gdb requires compiling the kernel
with debugging information inserted everywhere.
Rick Hohensee
www.clienux.com
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: X15 alpha release: as fast as TUX bu
Jim Gettys >The "put the time into a magic location in shared memory" goes back, as >far as I know, to Bob Scheifler or myself for the X Window System, >sometime >around 1984 or 1985: we put it into a page of shared memory where we used >a circular buffer scheme to put input events (keyboard/mice), so that >we could avoid the read system call overhead to get these events (and >more importantly, check between each request if there was input to >process). I don't think we ever claimed it was novel, just that we did Perhaps you'd seen an Amiga, and jealousy led to innovation. This is about when the Amiga came out, IIRC. AmigaDos is based on Tripos from Martin Richards at Cambridge, which was designed from the ground up to be "single-user, multi-tasking" in full view of the pre-existing elegance of UNIX. There is no MMU. One bad app takes the box down, but there are no seams and things scream when they work. There are some things about the Amiga UI that I want to go over again some time. My vague recollection is that devices UI served multiple readers implicitly. The structure of the code was nice too. Everything in linked lists from address 04. Execbase, my old IRC nick :o) Richards now has a beta port of Tripos to run on Linux called Cintpos. It's in BCPL of course, which nowadays can compile itself in 8 seconds on a P450. I had the pleasure of getting a thankyou from mr for noting that you have to enable shared memory in your Linux kernel to run Cintpos. Rick Hohensee www.clienux.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: X15 alpha release: as fast as TUX bu
Jim Gettys The put the time into a magic location in shared memory goes back, as far as I know, to Bob Scheifler or myself for the X Window System, sometime around 1984 or 1985: we put it into a page of shared memory where we used a circular buffer scheme to put input events (keyboard/mice), so that we could avoid the read system call overhead to get these events (and more importantly, check between each request if there was input to process). I don't think we ever claimed it was novel, just that we did Perhaps you'd seen an Amiga, and jealousy led to innovation. This is about when the Amiga came out, IIRC. AmigaDos is based on Tripos from Martin Richards at Cambridge, which was designed from the ground up to be single-user, multi-tasking in full view of the pre-existing elegance of UNIX. There is no MMU. One bad app takes the box down, but there are no seams and things scream when they work. There are some things about the Amiga UI that I want to go over again some time. My vague recollection is that devices UI served multiple readers implicitly. The structure of the code was nice too. Everything in linked lists from address 04. Execbase, my old IRC nick :o) Richards now has a beta port of Tripos to run on Linux called Cintpos. It's in BCPL of course, which nowadays can compile itself in 8 seconds on a P450. I had the pleasure of getting a thankyou from mr for noting that you have to enable shared memory in your Linux kernel to run Cintpos. Rick Hohensee www.clienux.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
seeoops, 3k all-Bash ksymoops alternative
In another few minutes I'll be posting the script itself to fa.linux.kernel that produced this ... FLAGS00010282 0 0 0 0 0 0 1 0 1 0 0 0 0 0 1 0 N O D I T S Z A P C e v i n r i e u a r s e r t a g r x r r T r c E p n o O i y eax:000a ebx:c012d175 c012d175t dsH3sm ecx: edx:0004 esi:c0132696 c0132690t crH3sm c01326b0t dofileCFA edi:c012d179 c012d175t dsH3sm c012f175t BYTESH3sm ebp:c012d075 c012d075t psH3sm STACK TRACE starting 4 calls out from oops c01080d3 c01080b0T kernel_thread c01080e0T exit_thread c0105000 c0105000T empty_bad_page c012a17d c012a150T kspamd c012a180t rw_swap_page_base c012d073 c012d06et reepeeetH3sm c012d075t psH3sm It takes 8 seconds on a P166, it's <4k, it's 100% Bash. FLAGS looks funny, but I dono. Season to taste. Rick Hohensee www.clienux.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
seeoops, 3k all-Bash ksymoops alternative
In another few minutes I'll be posting the script itself to fa.linux.kernel that produced this ... FLAGS00010282 0 0 0 0 0 0 1 0 1 0 0 0 0 0 1 0 N O D I T S Z A P C e v i n r i e u a r s e r t a g r x r r T r c E p n o O i y eax:000a ebx:c012d175 c012d175t dsH3sm ecx: edx:0004 esi:c0132696 c0132690t crH3sm c01326b0t dofileCFA edi:c012d179 c012d175t dsH3sm c012f175t BYTESH3sm ebp:c012d075 c012d075t psH3sm STACK TRACE starting 4 calls out from oops c01080d3 c01080b0T kernel_thread c01080e0T exit_thread c0105000 c0105000T empty_bad_page c012a17d c012a150T kspamd c012a180t rw_swap_page_base c012d073 c012d06et reepeeetH3sm c012d075t psH3sm It takes 8 seconds on a P166, it's 4k, it's 100% Bash. FLAGS looks funny, but I dono. Season to taste. Rick Hohensee www.clienux.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Single user linux
[EMAIL PROTECTED] wrote: > for those who didn't read that patch, i #define capable(), > suser(), and fsuser() to 1. the implication is all users > will have root capabilities. How is that not single user? I have been doing single-user oriented Linux/GNU/unix longer than anyone I'm aware of with exactly that focus. The one trivial patch I do to the kernel disgusts the core Linux developers for reasons unrelated to single user. cLIeNUX boots with 12 vt's logging in already as root. No kernel molestation. (But stay tuned ;o) Rather than me contributing further to the topic-skew, please have a browse at www.clienux.com Rick Hohensee cLIeNUX user 0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Single user linux
[EMAIL PROTECTED] wrote: for those who didn't read that patch, i #define capable(), suser(), and fsuser() to 1. the implication is all users will have root capabilities. How is that not single user? I have been doing single-user oriented Linux/GNU/unix longer than anyone I'm aware of with exactly that focus. The one trivial patch I do to the kernel disgusts the core Linux developers for reasons unrelated to single user. cLIeNUX boots with 12 vt's logging in already as root. No kernel molestation. (But stay tuned ;o) Rather than me contributing further to the topic-skew, please have a browse at www.clienux.com Rick Hohensee cLIeNUX user 0 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
one step up from vi .config
This is an example of a minimalist kernel config script using what I call
"subtractive synthesis", rather than the additive synthesis method of
make config and friends. This generates white-noise and then you filter
it, rather than painstakingly constructing your timbre one sinewave at a
time. Kinda. This example is for MCA-related pink noise, so to speak.
I think this may be related in a degenerate-case way to declarative
programming.
This leaves a lot to the user. It is based on the idea that hopefully
people with hardware with configuration interdependancies will be somewhat
cognizant of them.
I think this is close to a minimum for something that can generate any
desired config. I may have broken this somewhat tweaking it a bit to post,
but It's pretty handy when it works.
This is hereby public-domain-ified.
Rick Hohensee
:; cLIeNUX /dev/tty10 16:07:45 /
:;echo $DISTRO
cLIeNUX
.
## cLIeNUX Cheap Quick Dirty kernel config
## MAD (Microchannel Affection Disorder) example
## dependancies Linux sources and...
## sh, awk, clear, ed, your $VISUAL editor, rm, ls, mv, date
## The usual /tmp is /.tm in cLIeNUX
# function declaration
swap () { ## Last field, CONFIG_*, to second, after #
awk -- '
{
ORS=""
print "\n# " $NF
for ( i = 1 ; i < NF ; i++ ) print " "$i
} ' $1
}
# declarations
ARCH=i386
MCA=ONLY
C_INCLUDE_PATH=$C_INCLUDE_PATH:/source/kernel/$1
DATE=`date`
clear
echo -e "\t\t\tcLIeNUX linux/config\n\n\n\n
\ncollating base config data\n\n"
if a bla/Config.in file isn't in this list variable you won't see
### the options that Config.in file contains.
##Season to taste.
configlist="
arch/i386/config.in
fs/Config.in
drivers/char/Config.in
drivers/block/Config.in
drivers/scsi/Config.in
drivers/net/Config.in
fs/nls/Config.in
net/ipv4/Config.in
net/Config.in
net/sched/Config.in
net/irda/Config.in
net/irda/compressors/Config.in
drivers/net/hamradio/Config.in
drivers/net/irda/Config.in
drivers/block/paride/Config.in
drivers/char/ftape/Config.in
drivers/char/hfmodem/Config.in
drivers/char/joystick/Config.in
drivers/sound/lowlevel/Config.in
drivers/sound/Config.in
drivers/isdn/Config.in
drivers/video/Config.in
drivers/fc4/Config.in
fs/ncpfs/Config.in
net/ax25/Config.in
net/ipx/Config.in
"
## EXCLUDED from the above
## drivers/pnp/Config.in## put this back if not MCA
## drivers/cdrom/Config.in ## put this back if not MCA
## drivers/usb/Config.in
## net/irda/irlpt/Config.in
## net/irda/ircomm/Config.in
## net/irda/irlan/Config.in
## net/irda/irlpt/Config.in
## net/irda/ircomm/Config.in
## net/irda/irlan/Config.in
## net/irda/irlpt/Config.in
## drivers/acorn/net/Config.in Acorn
## drivers/acorn/scsi/Config.in
## drivers/acorn/block/Config.in
## drivers/acorn/char/Config.in
## drivers/sgi/Config.inSGI
## drivers/sbus/char/Config.in Mac
## drivers/sbus/audio/Config.in
## net/ipv6/Config.in
## drivers/fc4/Config.inFiber channel
cd linux
###MMMAIIINNN
echo > /.tm/BASE
## generate bulk CONFIG_ list.
#
for CF in $configlist
do
echo -en "\n# CONFIG\n# CONFIG " $CF "# CONFIG\n" >> /.tm/BASE
cat $CF >> /.tm/BASE
done
## format, then prune. Prune out experimental up front.
#
swap /.tm/BASE |grep "^# CONFIG" | grep -v -i "XPERIMEN" \
| cut -b 1-74 > /.tm/BASE2
rm /.tm/BASE
echo -e "\n\n\npruning...\n\n\n"
## convert choice types to "=y" and "=ym", then prune
#
ed < CONFIG
cat <> CONFIG
#
# Assuming you are seeing this via the cqdconfig script, what you do
# now is uncomment (remove the leftmost # from) the kernel options you
# want. Nothing is on now. The variables that are activated by you
# in here are then asserted as kernel sourcecode, and the
# kernel will be built accordingly. Variables can be =y or completely
# unset, and module options can also be m. If an option in here is =y you
# just have to uncomment it to assert it. If it's =ym you have to decide
# if you want it as a module or in the base kernel and pick y or m, IF you
# enable modules, and want that option. These options are additive.
# You can for example build a useless x86 kernel with just CONFIG_M386 and
# maybe a memsize option. In a useful kernel there may be some option
# interdependancies. Your only automated check on them with this
# non-rigorous config method is compiling and running the result. Most
# things that aren't non-interdependant single options will probably be
# known to people that have them. If you have problems use make config ,
# or read Documentation/Configuration.help.
#
# The cqdconfig script that generated th
one step up from vi .config
This is an example of a minimalist kernel config script using what I call
"subtractive synthesis", rather than the additive synthesis method of
make config and friends. This generates white-noise and then you filter
it, rather than painstakingly constructing your timbre one sinewave at a
time. Kinda. This example is for MCA-related pink noise, so to speak.
I think this may be related in a degenerate-case way to declarative
programming.
This leaves a lot to the user. It is based on the idea that hopefully
people with hardware with configuration interdependancies will be somewhat
cognizant of them.
I think this is close to a minimum for something that can generate any
desired config. I may have broken this somewhat tweaking it a bit to post,
but It's pretty handy when it works.
This is hereby public-domain-ified.
Rick Hohensee
:; cLIeNUX /dev/tty10 16:07:45 /
:;echo $DISTRO
cLIeNUX
.
## cLIeNUX Cheap Quick Dirty kernel config
## MAD (Microchannel Affection Disorder) example
## dependancies Linux sources and...
## sh, awk, clear, ed, your $VISUAL editor, rm, ls, mv, date
## The usual /tmp is /.tm in cLIeNUX
# function declaration
swap () { ## Last field, CONFIG_*, to second, after #
awk -- '
{
ORS=""
print "\n# " $NF
for ( i = 1 ; i NF ; i++ ) print " "$i
} ' $1
}
# declarations
ARCH=i386
MCA=ONLY
C_INCLUDE_PATH=$C_INCLUDE_PATH:/source/kernel/$1
DATE=`date`
clear
echo -e "\t\t\tcLIeNUX linux/config\n\n\n\n
\ncollating base config data\n\n"
if a bla/Config.in file isn't in this list variable you won't see
### the options that Config.in file contains.
##Season to taste.
configlist="
arch/i386/config.in
fs/Config.in
drivers/char/Config.in
drivers/block/Config.in
drivers/scsi/Config.in
drivers/net/Config.in
fs/nls/Config.in
net/ipv4/Config.in
net/Config.in
net/sched/Config.in
net/irda/Config.in
net/irda/compressors/Config.in
drivers/net/hamradio/Config.in
drivers/net/irda/Config.in
drivers/block/paride/Config.in
drivers/char/ftape/Config.in
drivers/char/hfmodem/Config.in
drivers/char/joystick/Config.in
drivers/sound/lowlevel/Config.in
drivers/sound/Config.in
drivers/isdn/Config.in
drivers/video/Config.in
drivers/fc4/Config.in
fs/ncpfs/Config.in
net/ax25/Config.in
net/ipx/Config.in
"
## EXCLUDED from the above
## drivers/pnp/Config.in## put this back if not MCA
## drivers/cdrom/Config.in ## put this back if not MCA
## drivers/usb/Config.in
## net/irda/irlpt/Config.in
## net/irda/ircomm/Config.in
## net/irda/irlan/Config.in
## net/irda/irlpt/Config.in
## net/irda/ircomm/Config.in
## net/irda/irlan/Config.in
## net/irda/irlpt/Config.in
## drivers/acorn/net/Config.in Acorn
## drivers/acorn/scsi/Config.in
## drivers/acorn/block/Config.in
## drivers/acorn/char/Config.in
## drivers/sgi/Config.inSGI
## drivers/sbus/char/Config.in Mac
## drivers/sbus/audio/Config.in
## net/ipv6/Config.in
## drivers/fc4/Config.inFiber channel
cd linux
###MMMAIIINNN
echo /.tm/BASE
## generate bulk CONFIG_ list.
#
for CF in $configlist
do
echo -en "\n# CONFIG\n# CONFIG " $CF "# CONFIG\n" /.tm/BASE
cat $CF /.tm/BASE
done
## format, then prune. Prune out experimental up front.
#
swap /.tm/BASE |grep "^# CONFIG" | grep -v -i "XPERIMEN" \
| cut -b 1-74 /.tm/BASE2
rm /.tm/BASE
echo -e "\n\n\npruning...\n\n\n"
## convert choice types to "=y" and "=ym", then prune
#
ed HEREDOC /.tm/BASE2
,s/ tristate '/=ym #/
,s/ bool '/=y #/
,s/'$//
g/Sun /d
g/Atari/d
g/Mac /d
g/Sparc/d
g/Amiga/d
wq
HEREDOC
## pro-Microchannel extreme prejudice
#
if test "$MCA" = "ONLY"
then
ed HEREDOC /.tm/BASE2
g/PCI/d
g/IDE/d
g/PNP/d
g/ISA/d
g/_APM_/d
wq
HEREDOC
fi
## header and assemble CONFIG
#
#
echo "## " `date`CONFIG
cat HEREDOC CONFIG
#
# Assuming you are seeing this via the cqdconfig script, what you do
# now is uncomment (remove the leftmost # from) the kernel options you
# want. Nothing is on now. The variables that are activated by you
# in here are then asserted as kernel sourcecode, and the
# kernel will be built accordingly. Variables can be =y or completely
# unset, and module options can also be m. If an option in here is =y you
# just have to uncomment it to assert it. If it's =ym you have to decide
# if you want it as a module or in the base kernel and pick y or m, IF you
# enable modules, and want that option. These options are additive.
# You can for example build a useless x86 kernel with just CONFIG_M386 and
# maybe a memsize option. In a useful kernel there may
What's a return stack worth?
cc does a lot of that, for locals I believe. LES, octal 304, is probably also actually a prevalent modR/M value. Otherwise things look mostly as one might expect. ff, 1, 2, 4 and 8 are probably frequent as literals. The fact that there are more 4's than 2's meshes with the fact that it's a 4 byte machine as far as vmlinux is concerned. There are a lot of 4's affiliated with that locals addressing mode. ASCII text in the kernel seems to be a relatively light factor. The apparent ratio between CALLs and RETs is about 1.6:1, which is the low end of what I expected. I suspect 1.6:1 is representative though. That interests me quite a lot. Is the exact ratio known? Has anyone ever built a 100% inlined kernel? Rick Hohensee www.clienux.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
What's a return stack worth?
lot of that, for locals I believe. LES, octal 304, is probably also actually a prevalent modR/M value. Otherwise things look mostly as one might expect. ff, 1, 2, 4 and 8 are probably frequent as literals. The fact that there are more 4's than 2's meshes with the fact that it's a 4 byte machine as far as vmlinux is concerned. There are a lot of 4's affiliated with that locals addressing mode. ASCII text in the kernel seems to be a relatively light factor. The apparent ratio between CALLs and RETs is about 1.6:1, which is the low end of what I expected. I suspect 1.6:1 is representative though. That interests me quite a lot. Is the exact ratio known? Has anyone ever built a 100% inlined kernel? Rick Hohensee www.clienux.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux localization
>> My work will concern with the internationalization of Linux >> So, could anybody tell me what kinds of features should be in the >> consideration when linux be localized from english to Japanese or chinese, >> say using 2 bytes character set. > >Most of the Linux userspace libraries are set up for handling UTF8 and >other internationalisations. Fonts are more of an issue and lack of application>translations. Filenames are defined to be UTF8. For the features that don't exist in Linux yet, you want to look closely at Plan 9 From Bell Labs, whence UTF-8 originates. Plan 9 for example has font cacheing in the kernel for huge glyph sets, if I read it right. The Plan 9 C compiler, written by Ken Thompson, author of UNIX and ed, specifically for writing Plan 9, is fully UTF-8 also. Everything else in Plan 9 is also UTF-8, from ed to libc to the GUI. Per-process namespaces are a Plan 9 idea also. That is the ultimate in localization. Plan 9 was released relatively recently under a license clearly patterned after the GPL. Congratulations once again to Richard Stallman. Thompson, Ritchie, Pike and so on have embraced his most important ideas. Plan 9 has a narrow platform base compared to Linux or NetBSD. I myself haven't been able to install it on my oldish hardware. You probably need to see it running, I suspect. My own Dotted Standard File Hierarchy mechanism in cLIeNUX (Linux/GNU/unix) may also be of interest. See my "/" below. That could easily be Japanese, Mandarin, Hindi, etc. ftp://linux01.gwdg.de/pub/cLIeNUX/descriptive/DSFH.html Rick Hohensee www.clienux.com :; cLIeNUX /dev/tty3 00:12:08 / :;d -d */ Linux//dev// help// mounts// suite// boot// device// incoming// owner//temp// command// floppy// log// source// configure//guest//lost+found// subroutines// :; cLIeNUX /dev/tty3 00:42:44 / :; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux localization
My work will concern with the internationalization of Linux So, could anybody tell me what kinds of features should be in the consideration when linux be localized from english to Japanese or chinese, say using 2 bytes character set. Most of the Linux userspace libraries are set up for handling UTF8 and other internationalisations. Fonts are more of an issue and lack of applicationtranslations. Filenames are defined to be UTF8. For the features that don't exist in Linux yet, you want to look closely at Plan 9 From Bell Labs, whence UTF-8 originates. Plan 9 for example has font cacheing in the kernel for huge glyph sets, if I read it right. The Plan 9 C compiler, written by Ken Thompson, author of UNIX and ed, specifically for writing Plan 9, is fully UTF-8 also. Everything else in Plan 9 is also UTF-8, from ed to libc to the GUI. Per-process namespaces are a Plan 9 idea also. That is the ultimate in localization. Plan 9 was released relatively recently under a license clearly patterned after the GPL. Congratulations once again to Richard Stallman. Thompson, Ritchie, Pike and so on have embraced his most important ideas. Plan 9 has a narrow platform base compared to Linux or NetBSD. I myself haven't been able to install it on my oldish hardware. You probably need to see it running, I suspect. My own Dotted Standard File Hierarchy mechanism in cLIeNUX (Linux/GNU/unix) may also be of interest. See my "/" below. That could easily be Japanese, Mandarin, Hindi, etc. ftp://linux01.gwdg.de/pub/cLIeNUX/descriptive/DSFH.html Rick Hohensee www.clienux.com :; cLIeNUX /dev/tty3 00:12:08 / :;d -d */ Linux//dev// help// mounts// suite// boot// device// incoming// owner//temp// command// floppy// log// source// configure//guest//lost+found// subroutines// :; cLIeNUX /dev/tty3 00:42:44 / :; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux installation problem (Microchannel)
> >Standard Red Hat has no MCA support (sorry much as I love my PS/2 its >rather >hard to make an honest business case for the huge amount of extra work to >build MCA boot disks/CD images). Debian I believe should install >straight >out >of the box on most MCA bus PC systems > >Alan > Hard if you want to pretend you're Microsoft. MCA may still be interesting for a bottom-feeder strategy. There are apparently still millions of them in storage. It seems the powers that be have made it harder for accountable organizations to discard computers, due to the lead content and so on. I have come off them myself, but the MAD types (Microchannel Affection Disorder) on Usenet still do strange things like upgrade thier CPUs and so on. My Microchannel stuff is in ftp://ftp.gwdg.de/pub/linux/install/clienux/MCA/ including what I believe was the first 2.88meg rawwrite. cLIeNUX was up until recently built on a 9595. The worst afflicted MAD individual is probably Charles Lasitter (one s) [EMAIL PROTECTED] . His MCA cLIeNUX spin-off should still cater to MCA quite nicely. Regular cLIeNUX should still install on MCA, I think, and is one dir up from the above URL. The newsgroup is comp.sys.ibm.ps2.hardware. Rick Hohensee www.clienux.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux installation problem (Microchannel)
Standard Red Hat has no MCA support (sorry much as I love my PS/2 its rather hard to make an honest business case for the huge amount of extra work to build MCA boot disks/CD images). Debian I believe should install straight out of the box on most MCA bus PC systems Alan Hard if you want to pretend you're Microsoft. MCA may still be interesting for a bottom-feeder strategy. There are apparently still millions of them in storage. It seems the powers that be have made it harder for accountable organizations to discard computers, due to the lead content and so on. I have come off them myself, but the MAD types (Microchannel Affection Disorder) on Usenet still do strange things like upgrade thier CPUs and so on. My Microchannel stuff is in ftp://ftp.gwdg.de/pub/linux/install/clienux/MCA/ including what I believe was the first 2.88meg rawwrite. cLIeNUX was up until recently built on a 9595. The worst afflicted MAD individual is probably Charles Lasitter (one s) [EMAIL PROTECTED] . His MCA cLIeNUX spin-off should still cater to MCA quite nicely. Regular cLIeNUX should still install on MCA, I think, and is one dir up from the above URL. The newsgroup is comp.sys.ibm.ps2.hardware. Rick Hohensee www.clienux.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Slightly OT] x86 PROM project
> >What does everybody think of the idea of trying to write a RISC PROM-like >BIOS for the x86 architecture? > >I've been tossing the idea around in my head for a while, and after I got >my first SGI I realized that something like this would be fairly useful. >Basically, I'm wondering if anybody is already doing something like this >(not linuxBIOS, though the code for that could be a useful >base). Thanks. Where this is on topic is in comp.lang.forth, since Open Firmware is a Forth. One of the c.l.f elders recently said he was going to wander off for a while and come back with what he could find out about this. I've copied a post or two on this subject to c.l.f since then. Related stuff; the FreeBSD bootloader is a Forth based on FICL, which is a Forth geared to be embedded in apps. In the hour or two I looked at that I couldn't get my bearings in the FBSD sources. I believe Open Firmware is bytecodes, and O.F. cards have actual drivers on them an O.F. host can request and thread into the O.F. dictionary (compile, in other words.) Most Forths are not bytecodes. Most Forths are address-threaded, or subroutine threaded, i.e. native code but implementing a true 2-stack virtual machine, or true 2-stack silicon. This is quite unlike Java, for example, which has Forth-like stack operators that are returnstack-frame-scoped, i.e. aren't an autonomous second stack. Rick Hohensee www.clienux.com My 3-stack machine and other oddities are in ftp://ftp.gwdg.de/pub/linux/install/clienux/interim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Slightly OT] x86 PROM project
What does everybody think of the idea of trying to write a RISC PROM-like BIOS for the x86 architecture? I've been tossing the idea around in my head for a while, and after I got my first SGI I realized that something like this would be fairly useful. Basically, I'm wondering if anybody is already doing something like this (not linuxBIOS, though the code for that could be a useful base). Thanks. Where this is on topic is in comp.lang.forth, since Open Firmware is a Forth. One of the c.l.f elders recently said he was going to wander off for a while and come back with what he could find out about this. I've copied a post or two on this subject to c.l.f since then. Related stuff; the FreeBSD bootloader is a Forth based on FICL, which is a Forth geared to be embedded in apps. In the hour or two I looked at that I couldn't get my bearings in the FBSD sources. I believe Open Firmware is bytecodes, and O.F. cards have actual drivers on them an O.F. host can request and thread into the O.F. dictionary (compile, in other words.) Most Forths are not bytecodes. Most Forths are address-threaded, or subroutine threaded, i.e. native code but implementing a true 2-stack virtual machine, or true 2-stack silicon. This is quite unlike Java, for example, which has Forth-like stack operators that are returnstack-frame-scoped, i.e. aren't an autonomous second stack. Rick Hohensee www.clienux.com My 3-stack machine and other oddities are in ftp://ftp.gwdg.de/pub/linux/install/clienux/interim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][CFT] per-process namespaces for Linux
>I'm more than willing to answer questions on the design of the thing - >just >ask. So far that's the best I can do - all documentation is a pile of >notes >+ CVS log. > >Cheers, >Al >PS: hopefully - back for good. That sounds like an especially fascinating pile of notes. Perhaps you could pile it next to the patch on the ftp site? Rick Hohensee :; cLIeNUX /dev/tty5 01:08:45 / :;ls -d */ Linux/dev/ help/ owner/temp/ boot/ device/ incoming/ source/ command/ floppy/ log/ subroutines/ configure/guest/mounts/ suite/ :; cLIeNUX /dev/tty5 01:08:55 / :; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][CFT] per-process namespaces for Linux
I'm more than willing to answer questions on the design of the thing - just ask. So far that's the best I can do - all documentation is a pile of notes + CVS log. Cheers, Al PS: hopefully - back for good. That sounds like an especially fascinating pile of notes. Perhaps you could pile it next to the patch on the ftp site? Rick Hohensee :; cLIeNUX /dev/tty5 01:08:45 / :;ls -d */ Linux/dev/ help/ owner/temp/ boot/ device/ incoming/ source/ command/ floppy/ log/ subroutines/ configure/guest/mounts/ suite/ :; cLIeNUX /dev/tty5 01:08:55 / :; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux OS boilerplate
Have you seen Janet_Reno? ftp://linux01.gwdg.de/pub/cLIeNUX/interim/Janet_Reno.tgz IIRC. Janet is an x86 bootsector that gets into protected mode and can use the AT BIOS in pmode interrupts. It's written with a bunch of m4 macros I call asmacs that I'm currently basing an assembler in Bash on. That's shasm in the same directory as Janet. Rick Hohensee www.cLIeNUX.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux OS boilerplate
Have you seen Janet_Reno? ftp://linux01.gwdg.de/pub/cLIeNUX/interim/Janet_Reno.tgz IIRC. Janet is an x86 bootsector that gets into protected mode and can use the AT BIOS in pmode interrupts. It's written with a bunch of m4 macros I call asmacs that I'm currently basing an assembler in Bash on. That's shasm in the same directory as Janet. Rick Hohensee www.cLIeNUX.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
dropcopyright script
... ## drop copyright notices to the bottoms of C files in current dir and # subs. # /* # CopYriGHt Guess Who 2001All reserves righted. # */ grep -ilr "copyright" . > tempdropcopyrights for f in `cat tempdropcopyrights` do ed $f
dropcopyright script
... ## drop copyright notices to the bottoms of C files in current dir and # subs. # /* # CopYriGHt Guess Who 2001All reserves righted. # */ grep -ilr "copyright" . tempdropcopyrights for f in `cat tempdropcopyrights` do ed $f HEREDOC /[Cc][oO][pP][yY][rR][iI]/ ?\/\*? .,/\*\//m$ wq HEREDOC done .... Rick Hohensee www.cLIeNUX.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Here's a nickel, kid.
Go write yourself a real OS. 45k text OS design sketch. Forth meets UNIX meets AmigaDos meets INTERCAL meets a Teletype Model 37. ftp://linux01.gwdg.de/pub/cLIeNUX/interim/design Rick Hohensee Forth, unix, cLIeNUX, and worse. - 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/
Here's a nickel, kid.
Go write yourself a real OS. 45k text OS design sketch. Forth meets UNIX meets AmigaDos meets INTERCAL meets a Teletype Model 37. ftp://linux01.gwdg.de/pub/cLIeNUX/interim/design Rick Hohensee Forth, unix, cLIeNUX, and worse. - 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/
unusual x86 bootsector
ftp://linux01.gwdg.de/pub/cLIeNUX/interim/Janet_Reno.tgz pmode bootsector handles pmode x86 int calls as real mode AT BIOS calls. I think it might even be reentrant. It worked on a clone but not on a PS/2 with int $0x10 $0x0e ... glass teletype output character. The DDD is the BIOS called from pmode, the other screen noise is straight pmode. Rick Hohensee [EMAIL PROTECTED] Forth, unix, cLIeNUX - 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/
unusual x86 bootsector
ftp://linux01.gwdg.de/pub/cLIeNUX/interim/Janet_Reno.tgz pmode bootsector handles pmode x86 int calls as real mode AT BIOS calls. I think it might even be reentrant. It worked on a clone but not on a PS/2 with int $0x10 $0x0e ... glass teletype output character. The DDD is the BIOS called from pmode, the other screen noise is straight pmode. Rick Hohensee [EMAIL PROTECTED] Forth, unix, cLIeNUX - 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/
Incorrectness for fun and profit
In 2.4 init/main.c we have... * Versions of gcc older than that listed below may actually compile * and link okay, but the end product can have subtle run time bugs. * To avoid associated bogus bug reports, we flatly refuse to compile * with a gcc that is known to be too old from the very beginning. */ #if __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 1) #error Sorry, your GCC is too old. It builds incorrect kernels. #endif Note that I've elided the 9 from the minor version number. I also tweaked the #define asmlinkage in whereveritis.h to look a bit more like 2.2, got rid of the arch=bla switch to gcc, and built the kernel I'm using at the moment with gcc 2.7.2.3. I'm looking for "subtle run time bugs". OK, I'm desparate for entertainment. That's a given. Where should I look? Everything I'm cognizant of so far is real pretty. I WANT BUGS! WHERE ARE THE BUGS? This is not a bogus bug report. This is a repeatable bug request. Incorrectly yours, Rick Hohensee :; cLIeNUX0 /dev/tty12 12:43:36 / :;get /Linux/version Linux version 2.4.0-test10 (@cLIeNUX) (gcc version 2.7.2.3) #10 Thu Nov 9 03:11:45 2000 :; cLIeNUX0 /dev/tty12 13:03:02 / :; - 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/
Incorrectness for fun and profit
In 2.4 init/main.c we have... * Versions of gcc older than that listed below may actually compile * and link okay, but the end product can have subtle run time bugs. * To avoid associated bogus bug reports, we flatly refuse to compile * with a gcc that is known to be too old from the very beginning. */ #if __GNUC__ 2 || (__GNUC__ == 2 __GNUC_MINOR__ 1) #error Sorry, your GCC is too old. It builds incorrect kernels. #endif Note that I've elided the 9 from the minor version number. I also tweaked the #define asmlinkage in whereveritis.h to look a bit more like 2.2, got rid of the arch=bla switch to gcc, and built the kernel I'm using at the moment with gcc 2.7.2.3. I'm looking for "subtle run time bugs". OK, I'm desparate for entertainment. That's a given. Where should I look? Everything I'm cognizant of so far is real pretty. I WANT BUGS! WHERE ARE THE BUGS? This is not a bogus bug report. This is a repeatable bug request. Incorrectly yours, Rick Hohensee :; cLIeNUX0 /dev/tty12 12:43:36 / :;get /Linux/version Linux version 2.4.0-test10 (@cLIeNUX) (gcc version 2.7.2.3) #10 Thu Nov 9 03:11:45 2000 :; cLIeNUX0 /dev/tty12 13:03:02 / :; - 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/
Fun with namespaces
cLIeNUX Core 1.4 visible dirs in / are all now symlinks. The only standard name is /dev. This means if you unpack cLIeNUX core on a clean ext2 partition, then install, say, SuSE over it, you can boot either one. On the same partition. If you do cLIeNUX first the SuSE dev's won't install. I guess. I did this with an old SuSE. To boot cLIeNUX you init=/.sbi/init . You can also unpack core1.4pre in, say, /cLIeNUX, and chroot to it. (/.bi/sh or whatever) If you for example are feeling nostalgic for libc5.4.46 . Or you want to check out Plan9 sam without X. core1.4pre unpacks to 35 meg. www.clienux.com Rick Hohensee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Patch to remove undefined C code
([EMAIL PROTECTED]) nobly encouraged empiricism thusly...
> Just to encourage empiricism, I usually check stuff like that with
>
> % cat > foo.c
> main(){
> int i;
> i = 1 , 2;
> printf("%d\n",i);
> }
> % gcc foo.c
> % ./a.out
> 1
>
> or similar if I'm confused.
Indeed. Further curiosity is sometimes promptly slaked in a manner
such as this...
:; cLIeNUX0 /dev/tty4 17:43:31 /
:;cc1
main(){
int i;
i = 1 , 2;
printf("%d\n",i);
}
:; cLIeNUX0 /dev/tty4 17:43:31 /
:;
The output of cc1 is not shown in the above. You'll have to
play that little ode to the joy of empiricism yourself.
Rick Hohensee
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Patch to remove undefined C code
([EMAIL PROTECTED]) nobly encouraged empiricism thusly...
Just to encourage empiricism, I usually check stuff like that with
% cat foo.c
main(){
int i;
i = 1 , 2;
printf("%d\n",i);
}
% gcc foo.c
% ./a.out
1
or similar if I'm confused.
Indeed. Further curiosity is sometimes promptly slaked in a manner
such as this...
:; cLIeNUX0 /dev/tty4 17:43:31 /
:;cc1
main(){
int i;
i = 1 , 2;
printf("%d\n",i);
}
:; cLIeNUX0 /dev/tty4 17:43:31 /
:;
The output of cc1 is not shown in the above. You'll have to
play that little ode to the joy of empiricism yourself.
Rick Hohensee
-
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/
