[9fans] GNU binutils: you can't make this shit up

[9fans] GNU binutils: you can't make this shit up

[Ronald G Minnich]

extern int regexec _RE_ARGS ((const regex_t *__restrict __preg,
			      const char *__restrict __string,
				size_t __nmatch,
			      regmatch_t __pmatch[__restrict_arr],
			      int __eflags));

dang, and it's getting a build error too :-)

Where do the compiler attribute hacks end and the code begin, we wonders?

make[4]: Entering directory 
`/home/rminnich/src/l4/afterburner/build/binutils-2.15.91.0.
2/gas'
gcc -DHAVE_CONFIG_H -I. 
-I/home/rminnich/src/l4/afterburner/extern/binutils-2.15.91.0.2/
gas -I. -D_GNU_SOURCE -I. 
-I/home/rminnich/src/l4/afterburner/extern/binutils-2.15.91.0.
2/gas -I../bfd 
-I/home/rminnich/src/l4/afterburner/extern/binutils-2.15.91.0.2/gas/confi
g 
-I/home/rminnich/src/l4/afterburner/extern/binutils-2.15.91.0.2/gas/../include 
-I/home
/rminnich/src/l4/afterburner/extern/binutils-2.15.91.0.2/gas/.. 
-I/home/rminnich/src/l4/
afterburner/extern/binutils-2.15.91.0.2/gas/../bfd 
-I/home/rminnich/src/l4/afterburner/e
xtern/binutils-2.15.91.0.2/gas/../intl -I../intl 
-DLOCALEDIR="\"/home/rminnich/src/l4/af
terburner/usr/share/locale\""   -W -Wall -Wstrict-prototypes 
-Wmissing-prototypes -g -O2
  -c /home/rminnich/src/l4/afterburner/extern/binutils-2.15.91.0.2/gas/app.c
In file included from ./targ-cpu.h:1,
                  from 
/home/rminnich/src/l4/afterburner/extern/binutils-2.15.91.0.2/gas/
config/obj-elf.h:42,
                  from ./obj-format.h:1,
                  from 
/home/rminnich/src/l4/afterburner/extern/binutils-2.15.91.0.2/gas/
config/te-linux.h:4,
                  from ./targ-env.h:1,
                  from 
/home/rminnich/src/l4/afterburner/extern/binutils-2.15.91.0.2/gas/
as.h:629,
                  from 
/home/rminnich/src/l4/afterburner/extern/binutils-2.15.91.0.2/gas/
app.c:30:
/home/rminnich/src/l4/afterburner/extern/binutils-2.15.91.0.2/gas/config/tc-i386.h:457: 

error: array type has incomplete element type

ya hoo!

ron

Re: [9fans] GNU binutils: you can't make this shit up

[Andy Newman]

Ronald G Minnich wrote:
> 
> extern int regexec _RE_ARGS ((const regex_t *__restrict __preg,
> 			      const char *__restrict __string,
> 				size_t __nmatch,
> 			      regmatch_t __pmatch[__restrict_arr],
> 			      int __eflags));
> 
> dang, and it's getting a build error too :-)
> 
> Where do the compiler attribute hacks end and the code begin, we wonders?

What bright spark thought the double underscores on the
arg names was a good idea.  Could be worse. It could be
C++ with all those highly readable '<', '>' and '::'
sequences. But luckily there's only one array parameter
so the error is not that much of a challenge.

Re: [9fans] GNU binutils: you can't make this shit up

[Ronald G Minnich]

Andy Newman wrote:
>  But luckily there's only one array parameter
> so the error is not that much of a challenge.


um. you have not waded through the GNU ifdef hell, I'm guessing.

I have an even better one, in which a struct is forward declared, and 
included, and so on .... and it's still not found as a defined struct.

And, of course, you can't just cd into a binutils directory and try to 
make something; no sir, because about 30 environment variables are 
missing at that point.

whew. Sorry, this is trying to see if the L4 microkernel can run a Plan 
9 guest.

ron

Re: [9fans] GNU binutils: you can't make this shit up

[erik quanstrom]

l4 depends on all that gnu stuff?

it's hard to imagine something that bills itself as the ultimate
microkernel depending on the ultimate macro environment.

- erik

Ronald G Minnich <rminnich@lanl.gov> writes

| 
| Andy Newman wrote:
| >  But luckily there's only one array parameter
| > so the error is not that much of a challenge.
| 
| 
| um. you have not waded through the GNU ifdef hell, I'm guessing.
| 
| I have an even better one, in which a struct is forward declared, and 
| included, and so on .... and it's still not found as a defined struct.
| 
| And, of course, you can't just cd into a binutils directory and try to 
| make something; no sir, because about 30 environment variables are 
| missing at that point.
| 
| whew. Sorry, this is trying to see if the L4 microkernel can run a Plan 
| 9 guest.
| 
| ron

Re: [9fans] GNU binutils: you can't make this shit up

[David Leimbach]

On 1/15/06, erik quanstrom <quanstro@quanstro.net> wrote:
> l4 depends on all that gnu stuff?
>
> it's hard to imagine something that bills itself as the ultimate
> microkernel depending on the ultimate macro environment.
>
> - erik
>

Depends on the implementation... L4 Pistachio requires C++ and a
particular version of gcc.  I've built it on my Mac OS X environment
successfully and run piggybacked images since we had no multi-boot
capable loaders for OpenFirmware at the time.

dave

> Ronald G Minnich <rminnich@lanl.gov> writes
>
> |
> | Andy Newman wrote:
> | >  But luckily there's only one array parameter
> | > so the error is not that much of a challenge.
> |
> |
> | um. you have not waded through the GNU ifdef hell, I'm guessing.
> |
> | I have an even better one, in which a struct is forward declared, and
> | included, and so on .... and it's still not found as a defined struct.
> |
> | And, of course, you can't just cd into a binutils directory and try to
> | make something; no sir, because about 30 environment variables are
> | missing at that point.
> |
> | whew. Sorry, this is trying to see if the L4 microkernel can run a Plan
> | 9 guest.
> |
> | ron
>

Re: [9fans] GNU binutils: you can't make this shit up

[Eirik Johnson]

It does seem odd to use the GNU extensions there,
especially as L4Ka people can't be too cozy with FSF
people, the whole L4Ka::Pistachio is released under
the BSD license.

Quinn

--- David Leimbach <leimy2k@gmail.com> wrote:

> On 1/15/06, erik quanstrom <quanstro@quanstro.net>
> wrote:
> > l4 depends on all that gnu stuff?
> >
> > it's hard to imagine something that bills itself
> as the ultimate
> > microkernel depending on the ultimate macro
> environment.
> >
> > - erik
> >
> 
> Depends on the implementation... L4 Pistachio
> requires C++ and a
> particular version of gcc.  I've built it on my Mac
> OS X environment
> successfully and run piggybacked images since we had
> no multi-boot
> capable loaders for OpenFirmware at the time.
> 
> dave
> 
> > Ronald G Minnich <rminnich@lanl.gov> writes
> >
> > |
> > | Andy Newman wrote:
> > | >  But luckily there's only one array parameter
> > | > so the error is not that much of a challenge.
> > |
> > |
> > | um. you have not waded through the GNU ifdef
> hell, I'm guessing.
> > |
> > | I have an even better one, in which a struct is
> forward declared, and
> > | included, and so on .... and it's still not
> found as a defined struct.
> > |
> > | And, of course, you can't just cd into a
> binutils directory and try to
> > | make something; no sir, because about 30
> environment variables are
> > | missing at that point.
> > |
> > | whew. Sorry, this is trying to see if the L4
> microkernel can run a Plan
> > | 9 guest.
> > |
> > | ron
> >
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [9fans] GNU binutils: you can't make this shit up

[Bruce Ellis]

anyone who is serious trying anything starting with "g" with
kenc (apart from "grep") is barking up the wrong
mountain ave.

brucee

On 1/18/06, Eirik Johnson <falmarian@yahoo.com> wrote:
> It does seem odd to use the GNU extensions there,
> especially as L4Ka people can't be too cozy with FSF
> people, the whole L4Ka::Pistachio is released under
> the BSD license.
>
> Quinn
>
> --- David Leimbach <leimy2k@gmail.com> wrote:
>
> > On 1/15/06, erik quanstrom <quanstro@quanstro.net>
> > wrote:
> > > l4 depends on all that gnu stuff?
> > >
> > > it's hard to imagine something that bills itself
> > as the ultimate
> > > microkernel depending on the ultimate macro
> > environment.
> > >
> > > - erik
> > >
> >
> > Depends on the implementation... L4 Pistachio
> > requires C++ and a
> > particular version of gcc.  I've built it on my Mac
> > OS X environment
> > successfully and run piggybacked images since we had
> > no multi-boot
> > capable loaders for OpenFirmware at the time.
> >
> > dave
> >
> > > Ronald G Minnich <rminnich@lanl.gov> writes
> > >
> > > |
> > > | Andy Newman wrote:
> > > | >  But luckily there's only one array parameter
> > > | > so the error is not that much of a challenge.
> > > |
> > > |
> > > | um. you have not waded through the GNU ifdef
> > hell, I'm guessing.
> > > |
> > > | I have an even better one, in which a struct is
> > forward declared, and
> > > | included, and so on .... and it's still not
> > found as a defined struct.
> > > |
> > > | And, of course, you can't just cd into a
> > binutils directory and try to
> > > | make something; no sir, because about 30
> > environment variables are
> > > | missing at that point.
> > > |
> > > | whew. Sorry, this is trying to see if the L4
> > microkernel can run a Plan
> > > | 9 guest.
> > > |
> > > | ron
> > >
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>

Re: [9fans] GNU binutils: you can't make this shit up

[alexandr babic]

i think 9fans should write plan9 native programs not trying other waste
to import.

alexandr.


Bruce Ellis píše v Čt 19. 01. 2006 v 00:45 +1100:
> anyone who is serious trying anything starting with "g" with
> kenc (apart from "grep") is barking up the wrong
> mountain ave.
> 
> brucee
> 

Re: [9fans] GNU binutils: you can't make this shit up

[Ronald G Minnich]

alexandr babic wrote:
> i think 9fans should write plan9 native programs not trying other waste
> to import.

right, but I was not trying to do that.

I'm trying to see
- if I can get L4KA to build (fails)
- get L4KA to boot linux (predicated on previous step)
- run Plan 9 as an L4KA guest (predicated on previous step)

  so far, failure all around.

"he who lives by the gcc hack, dies by the gcc hack" (even on linux)

ron

Re: [9fans] GNU binutils: you can't make this shit up

[Bruce Ellis]

beck wrote a song "gcc makes me wanta do crack" - well
at least that what it is after i edited it.

brucee

On 1/19/06, Ronald G Minnich <rminnich@lanl.gov> wrote:
> alexandr babic wrote:
> > i think 9fans should write plan9 native programs not trying other waste
> > to import.
>
> right, but I was not trying to do that.
>
> I'm trying to see
> - if I can get L4KA to build (fails)
> - get L4KA to boot linux (predicated on previous step)
> - run Plan 9 as an L4KA guest (predicated on previous step)
>
>  so far, failure all around.
>
> "he who lives by the gcc hack, dies by the gcc hack" (even on linux)
>
> ron
>

Re: [9fans] GNU binutils: you can't make this shit up

[alexandr babic]

programer's life could be easier and happier if he stays within plan9.
i think that i became reducionist thanx to plan9 :-)

* no horrible graphic desktops (kde, gnome, windows) only pure and nice
rio.

* no giant graphic libraries (gtk, qt, motif) only libdraw

AND LIFE IS SO EASY :-)

alexandr

Bruce Ellis píše v Čt 19. 01. 2006 v 03:45 +1100:
> beck wrote a song "gcc makes me wanta do crack" - well
> at least that what it is after i edited it.
> 
> brucee
> 
> On 1/19/06, Ronald G Minnich <rminnich@lanl.gov> wrote:
> > alexandr babic wrote:
> > > i think 9fans should write plan9 native programs not trying other waste
> > > to import.
> >
> > right, but I was not trying to do that.
> >
> > I'm trying to see
> > - if I can get L4KA to build (fails)
> > - get L4KA to boot linux (predicated on previous step)
> > - run Plan 9 as an L4KA guest (predicated on previous step)
> >
> >  so far, failure all around.
> >
> > "he who lives by the gcc hack, dies by the gcc hack" (even on linux)
> >
> > ron
> >

Re: [9fans] GNU binutils: you can't make this shit up

[Bruce Ellis]

well said.  is this better than a town hall meeting?

yes.

rev brucee

On 1/19/06, alexandr babic <alexandr@babi.cz> wrote:
> programer's life could be easier and happier if he stays within plan9.
> i think that i became reducionist thanx to plan9 :-)
>
> * no horrible graphic desktops (kde, gnome, windows) only pure and nice
> rio.
>
> * no giant graphic libraries (gtk, qt, motif) only libdraw
>
> AND LIFE IS SO EASY :-)
>
> alexandr
>
> Bruce Ellis píše v Čt 19. 01. 2006 v 03:45 +1100:
> > beck wrote a song "gcc makes me wanta do crack" - well
> > at least that what it is after i edited it.
> >
> > brucee
> >
> > On 1/19/06, Ronald G Minnich <rminnich@lanl.gov> wrote:
> > > alexandr babic wrote:
> > > > i think 9fans should write plan9 native programs not trying other waste
> > > > to import.
> > >
> > > right, but I was not trying to do that.
> > >
> > > I'm trying to see
> > > - if I can get L4KA to build (fails)
> > > - get L4KA to boot linux (predicated on previous step)
> > > - run Plan 9 as an L4KA guest (predicated on previous step)
> > >
> > >  so far, failure all around.
> > >
> > > "he who lives by the gcc hack, dies by the gcc hack" (even on linux)
> > >
> > > ron
> > >
>
>

Re: [9fans] GNU binutils: you can't make this shit up

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 2195 bytes --]

On 1/18/06, Ronald G Minnich <rminnich@lanl.gov> wrote:
>
> alexandr babic wrote:
> > i think 9fans should write plan9 native programs not trying other waste
> > to import.
>
> right, but I was not trying to do that.
>
> I'm trying to see
> - if I can get L4KA to build (fails)



Never had a problem here... I even cross compile from Mac OS X.  Just gotta
use the right version of the compiler.  [Stupid, I agree, and circle gets
the square]

See this for some potential hints... Of course it's PPC specific but it may
help you figure out why stuff won't build in general.

http://l4ka.org/projects/pistachio/powerpc/ppc-build.txt

Been a while since I've tried this myself but I was very successful back
then [1.5 years ago?]

- get L4KA to boot linux (predicated on previous step)


I think I only ever ran a Live CD of this... but it worked great with the
Dresden Realtime OPerating Systems demo floppy or CD or whatever it was...
They have a really weird windowing system for launching Debian on L4
instances.... this was quite a bit before Xen mind you and they were doing
the same things but on a microkernel that had less suck than mach.

- run Plan 9 as an L4KA guest (predicated on previous step)


I'd try that :)  The weird thing is you can load l4-linux and then write an
OS personality in another address space and use the L4 messaging to use
linux as something of a driver repository.  There are even some performance
measurments of the impact of this, which is a ton better than trying to
write drivers in userspace with mach.  I wouldn't try 10Gbit ethernet that
way but for disks and some other devices this seems to work kind of well.

Abstract here:
http://os.inf.tu-dresden.de/EZAG/old/ws2004/abstracts/abstract_20041012.xml

Sometimes I wish I could just get paid to play with esoteric weird OS junk
all day.

  so far, failure all around.
>
> "he who lives by the gcc hack, dies by the gcc hack" (even on linux)



yep, I'm at least glad that I see more and more -std=c99 in the FreeBSD
build system.  Less and less gcc-isms is a big plus, even if I don't care
for C99 so much [which could be worse].


ron
>

[-- Attachment #2: Type: text/html, Size: 3350 bytes --]

Re: [9fans] GNU binutils: you can't make this shit up

[Ronald G Minnich]

david, that's a useful web page but the issues come in with afterburner, 
but I'll keep trying.

in spare time.

ron

Re: [9fans] GNU binutils: you can't make this shit up

[Eirik Johnson]

There is something to be said for microkernels
they allow for a lot less headaches with kernel
development, and it could drastically improve plan 9's
portability, a key feature.
Also, the multi-server approach taken by the GNU/Hurd
is innovative and well suited to SMP and distributed
environments.  However, the FSF has a role and the GNU
project is (and should be) a side project for them. 
The real problem with it, though, is that C (like plan
9) was designed with portability as a major feature,
and the GNU extensions in GCC aren't helping
portability.  It's kinda like microsoft's C#, they may
be wonderful features, but you missed the whole point.


--- alexandr babic <alexandr@babi.cz> wrote:

> i think 9fans should write plan9 native programs not
> trying other waste
> to import.
> 
> alexandr.
> 
> 
> Bruce Ellis pí¹e v Èt 19. 01. 2006 v 00:45 +1100:
> > anyone who is serious trying anything starting
> with "g" with
> > kenc (apart from "grep") is barking up the wrong
> > mountain ave.
> > 
> > brucee
> > 
> 
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [9fans] GNU binutils: you can't make this shit up

[Charles Forsyth]

> There is something to be said for microkernels
> they allow for a lot less headaches with kernel
> development, and it could drastically improve plan 9's
> portability, a key feature.

term% pwd
/usr/forsyth/src/xen3/xen-unstable/xen/arch/x86
term% wc -l mm.c shadow32.c shadow_guest32.c 
   3519 mm.c
   3397 shadow32.c
     18 shadow_guest32.c
   6934 total
# and that could be the tip of an iceberg, since that's x86-only

# now let's look at several non-micro/hyper kernels
term% cd /sys/src/9/pc
term% wc -l mmu.c
   1043 mmu.c

term% cd /usr/inferno/os/pc
term% wc -l mmu.c
    321 mmu.c

now if you're using the first implementation above,
you still also need something like the second or third as well (but a little different).

that's a hypervisor (but one that is claimed in a paper to be `microkernels done right').
its code is much bigger because it actually does much more than 9's or Inferno's.
i'm sure last time i looked (which to be fair was years ago)
mach had quite a bit of complex mmu code too.

which is likely to give you more headaches, and how strong?
perhaps we should have an ibuprofen rating for kernels?

portability? i have done kernels (including small micro-ish ones) myself,
and i have worked with other systems extensively over the years.
in my experience, some of the interfaces the micro/hypers present
is HARDER to drive than the underlying hardware, possibly more
frustrating, not as well documented, and changes.  and of course
there's more code in the end.  somtimes much more.
it wouldn't be so bad if people hadn't forgotten an important lesson
from THE: the idea is for each layer to provide increasingly higher levels
of abstraction, the better to reason about.  of course, in several cases, the
newer systems are the way they are to make porting Linux easier (well,
that's my impression), presumably on the grounds that its interfaces are
all over the place, x86-oriented, and hard to change.

then there are the interfaces for device drivers...

not that i'm bitter.

the way to get good portability is to have clear, well-designed interfaces
that abstract away from hardware peculiarities, and map those to the
hardware (rather than, say, reflecting in the interfaces the union of every
peculiarity of all hardware known to you at the time).

some of the hard bits about kernel development are:
- getting accurate documentation for the processor, devices, existing bootstrap, etc.
- getting anything loaded into the wretched machine at all
- deciding how your kernel should look, what it should do, how it should change
- working out a good infrastructure for networks, devices coming and going, power, etc.
- finding time and/or money to do any of it

now, while it can be really tedious when you get yourself into the state where
the hardware resets without notice (and worse, takes quite some time to get to that state,
or requires ... something ... but what is it???), it often isn't something that would
be fixed by a micro-kernel, but rather by better hardware, documentation, more careful
coding, fewer interruptions, more time to think, more energy, and of course more intelligence.
lacking any or all of these, it's still usually easier to debug a component of a smaller system with a
straightforward model overall.  that might be true of some micro-kernels, but not all, and
it isn't limited to them; a more `conventional' kernel can be quite acceptably modular.

Re: [9fans] GNU binutils: you can't make this shit up

[Bruce Ellis]

can i put this in m book?

--- forsyth
the way to get good portability is to have clear, well-designed interfaces
that abstract away from hardware peculiarities, and map those to the
hardware (rather than, say, reflecting in the interfaces the union of every
peculiarity of all hardware known to you at the time).

some of the hard bits about kernel development are:
- getting accurate documentation for the processor, devices, existing
bootstrap, etc.
- getting anything loaded into the wretched machine at all
- deciding how your kernel should look, what it should do, how it should change
- working out a good infrastructure for networks, devices coming and
going, power, etc.
- finding time and/or money to do any of it

Re: [9fans] GNU binutils: you can't make this shit up

[erik quanstrom]

Eirik Johnson <falmarian@yahoo.com> writes

| 
| There is something to be said for microkernels
| they allow for a lot less headaches with kernel
| development, and it could drastically improve plan 9's
| portability, a key feature.

"microkernels" cover a broad range. mach is
bigger than the plan 9 kernel. bigger than the linux kernel, even.
and linux is 90% device drivers.

i hold out some hope for l4. 

| Also, the multi-server approach taken by the GNU/Hurd
| is innovative and well suited to SMP and distributed
| environments. 

what's innovative about the hurd? unless i'm missing something
plan9 fileservers are isomorphic with hurd daemons, conceptually.
the major difference being, in the hurd a server exports a random
interface, in plan9 a server exports a filesystem.
hurd isn't even an os. it needs a microkernel.

 However, the FSF has a role and the GNU
| project is (and should be) a side project for them. 
| The real problem with it, though, is that C (like plan
| 9) was designed with portability as a major feature,
| and the GNU extensions in GCC aren't helping
| portability.  It's kinda like microsoft's C#, they may
| be wonderful features, but you missed the whole point.

Re: [9fans] GNU binutils: you can't make this shit up

[Bruce Ellis]

there is nothing innovative about hurd, not even the fact
that it doesn't work and has taken years to get so unstable.

brucee

On 1/19/06, erik quanstrom <quanstro@quanstro.net> wrote:
>
> Eirik Johnson <falmarian@yahoo.com> writes
>
> |
> | There is something to be said for microkernels
> | they allow for a lot less headaches with kernel
> | development, and it could drastically improve plan 9's
> | portability, a key feature.
>
> "microkernels" cover a broad range. mach is
> bigger than the plan 9 kernel. bigger than the linux kernel, even.
> and linux is 90% device drivers.
>
> i hold out some hope for l4.
>
> | Also, the multi-server approach taken by the GNU/Hurd
> | is innovative and well suited to SMP and distributed
> | environments.
>
> what's innovative about the hurd? unless i'm missing something
> plan9 fileservers are isomorphic with hurd daemons, conceptually.
> the major difference being, in the hurd a server exports a random
> interface, in plan9 a server exports a filesystem.
> hurd isn't even an os. it needs a microkernel.
>
>  However, the FSF has a role and the GNU
> | project is (and should be) a side project for them.
> | The real problem with it, though, is that C (like plan
> | 9) was designed with portability as a major feature,
> | and the GNU extensions in GCC aren't helping
> | portability.  It's kinda like microsoft's C#, they may
> | be wonderful features, but you missed the whole point.
>

Re: [9fans] GNU binutils: you can't make this shit up

[Ronald G Minnich]

Eirik Johnson wrote:
> There is something to be said for microkernels
> they allow for a lot less headaches with kernel
> development, and it could drastically improve plan 9's
> portability, a key feature.

it's not april fool's

ron

Re: [9fans] GNU binutils: you can't make this shit up

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 3372 bytes --]

On 1/19/06, Eirik Johnson <falmarian@yahoo.com> wrote:
>
> There is something to be said for microkernels
> they allow for a lot less headaches with kernel
> development, and it could drastically improve plan 9's
> portability, a key feature.



Disagree, to some extent.  Microkernels tie you down to a particular set of
abstractions for writing OS code.  I think a lot of time is spent trying to
figure out how to morph the primitives that are exposed by the microkernel
API into what you're trying to express in your kernel.

EROS, for example, multiplexed a single system call to create all the OS
primitives for the system.
L4 really only has 7 system calls, but also has several APIs available that
combine things in different, and hopefully not pessimistic ways to make
things easier.  It's a layer of abstractions on another layer of
abstractions.



> Also, the multi-server approach taken by the GNU/Hurd
> is innovative and well suited to SMP and distributed
> environments.  However, the FSF has a role and the GNU
> project is (and should be) a side project for them.
> The real problem with it, though, is that C (like plan
> 9) was designed with portability as a major feature,
> and the GNU extensions in GCC aren't helping
> portability.  It's kinda like microsoft's C#, they may
> be wonderful features, but you missed the whole point.


True, and this may have caused very serious problems with development.  For
a long time, possibly even still today you were limited to 2GB partitions.
Also there was no pppd driver.  I have a hunch that their multi-server
design stuck them into a place where these things became hard to do
correctly.  I have seen 2 different patches floating around for Hurd to add
>2GB partitions as well as pppd [borrowed from FreeBSD in fact] but neither
seemed to make it into into the main source tree because, it just wasn't
quite correct.

At some point, HURD developers became so frustrated with Mach, they switched
to L4.  I followed a lot of this development as a lurker... and I'd have to
say that it doesn't look good again for progress and people inside FSF are
questioning the design *again*.

Now those examples aside, I know for a fact you can write useful OSes with a
microkernel.  I've seen and used a few of them.  Someone even took the Io
programming language and ported it to L4 to make what appears to be
something on the lines of a ROM BASIC for an OS :).  This might be really
good in certain embedded applications, who knows.

Also the HoP/House project, which takes the GHC Haskell runtime and turns it
into an OS via a special Monad for hardware abstractions, looks like it may
also get ported to L4.

There's no magic wand for OS development.

> --- alexandr babic <alexandr@babi.cz> wrote:
>
> > i think 9fans should write plan9 native programs not
> > trying other waste
> > to import.
> >
> > alexandr.
> >
> >
> > Bruce Ellis pí¹e v Èt 19. 01. 2006 v 00:45 +1100:
> > > anyone who is serious trying anything starting
> > with "g" with
> > > kenc (apart from "grep") is barking up the wrong
> > > mountain ave.
> > >
> > > brucee
> > >
> >
> >
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>

[-- Attachment #2: Type: text/html, Size: 4252 bytes --]

Re: [9fans] GNU binutils: you can't make this stuff up

[Brantley Coile]

Microkernels are to OS design what Unicode was to compiler design.

Re: [9fans] GNU binutils: you can't make this stuff up

[Bruce Ellis]

c'mon microcode is fun.  guido is full of it - all concurrent.  the easiest
example is string equality (rather popular really).  doodling in the sand
on the beach helps with microcode design.

brucee

On 1/20/06, Brantley Coile <brantley@coraid.com> wrote:
> Microkernels are to OS design what Unicode was to compiler design.

Re: [9fans] GNU binutils: you can't make this stuff up

[erik quanstrom]

what does unicode have to do with compiler design? 

does "microkernel" mean anything specific? i'm not convinced that it does.

- erik

Brantley Coile <brantley@coraid.com> writes

| 
| Microkernels are to OS design what Unicode was to compiler design.

Re: [9fans] GNU binutils: you can't make this shit up

[Ronald G Minnich]

erik quanstrom wrote:
> l4 depends on all that gnu stuff?

the afterburner stuff comes with a full binutils &tc.

gcc 4.0 can not build the version of binutils that comes with afterburner.

ron

Re: [9fans] GNU binutils: you can't make this shit up

[David Leimbach]

On 1/15/06, Ronald G Minnich <rminnich@lanl.gov> wrote:
> Andy Newman wrote:
> >  But luckily there's only one array parameter
> > so the error is not that much of a challenge.
>
>
> um. you have not waded through the GNU ifdef hell, I'm guessing.
>
> I have an even better one, in which a struct is forward declared, and
> included, and so on .... and it's still not found as a defined struct.
>
> And, of course, you can't just cd into a binutils directory and try to
> make something; no sir, because about 30 environment variables are
> missing at that point.
>
> whew. Sorry, this is trying to see if the L4 microkernel can run a Plan
> 9 guest.
>

Using Pistachio as a hypervisor are we?  Trying to afterburn?  What
are you going for.  I've some experience with L4 and L4-linux.

Pistachio seems to only work with a particular version of gcc too...

Dave

> ron
>

Re: [9fans] GNU binutils: you can't make this shit up

[Ronald G Minnich]

David Leimbach wrote:

> Using Pistachio as a hypervisor are we?  Trying to afterburn?  What
> are you going for.  I've some experience with L4 and L4-linux.
> 
> Pistachio seems to only work with a particular version of gcc too...

oh hell.

yeah, I wanted to try to afterburn.

ron

Re: [9fans] GNU binutils: you can't make this shit up

[Bruce Ellis]

Burn it!

brucee

On 1/17/06, Ronald G Minnich <rminnich@lanl.gov> wrote:
> David Leimbach wrote:
>
> > Using Pistachio as a hypervisor are we?  Trying to afterburn?  What
> > are you going for.  I've some experience with L4 and L4-linux.
> >
> > Pistachio seems to only work with a particular version of gcc too...
>
> oh hell.
>
> yeah, I wanted to try to afterburn.
>
> ron
>

Re: [9fans] GNU binutils: you can't make this shit up

[Andy Newman]

Ronald G Minnich wrote:
> Andy Newman wrote:
> > But luckily there's only one array parameter
> >so the error is not that much of a challenge.
> 
> 
> um. you have not waded through the GNU ifdef hell, I'm guessing.

Oh yes. Fun stuff.  I just love autoconf et al.  Nightmare time.
It's easier without it.  Here in Oz there was an old Sara Lee
ad... Layer upon layer upon layer...

Re: [9fans] GNU binutils: you can't make this shit up

[Bruce Ellis]

you can fight all you like getting a g* something to work . have fun.
i can find more absurd examples than ron's if i am willing to look
at the zillions of lines of code.  i agree with andy, but the thunderstorms
are making my UPS's beep too much.

brucee

On 1/16/06, Andy Newman <andy.newman@silverbrookresearch.com> wrote:
> Ronald G Minnich wrote:
> > Andy Newman wrote:
> > > But luckily there's only one array parameter
> > >so the error is not that much of a challenge.
> >
> >
> > um. you have not waded through the GNU ifdef hell, I'm guessing.
>
> Oh yes. Fun stuff.  I just love autoconf et al.  Nightmare time.
> It's easier without it.  Here in Oz there was an old Sara Lee
> ad... Layer upon layer upon layer...
>

Re: [9fans] GNU binutils: you can't make this shit up

[erik quanstrom]

you gotta love it when you see:

checking sizeof(char)

they built a unix compatability system. but didn't know when to
stop.

and it still doesn't work for many things on AIX.

- erik

Andy Newman <andy.newman@silverbrookresearch.com> writes

| 
| Ronald G Minnich wrote:
| > Andy Newman wrote:
| > > But luckily there's only one array parameter
| > >so the error is not that much of a challenge.
| > 
| > 
| > um. you have not waded through the GNU ifdef hell, I'm guessing.
| 
| Oh yes. Fun stuff.  I just love autoconf et al.  Nightmare time.
| It's easier without it.  Here in Oz there was an old Sara Lee
| ad... Layer upon layer upon layer...

Re: [9fans] GNU binutils: you can't make this shit up

[Bruce Ellis]

clueless reckless network behaviour is how it is described on the
network violation tickets.  boydo and ranum would have issued
one without hesitation.  check the size of anything but get it right.

brucee

On 1/16/06, erik quanstrom <quanstro@quanstro.net> wrote:
> you gotta love it when you see:
>
> checking sizeof(char)
>
> they built a unix compatability system. but didn't know when to
> stop.
>
> and it still doesn't work for many things on AIX.
>
> - erik
>
> Andy Newman <andy.newman@silverbrookresearch.com> writes
>
> |
> | Ronald G Minnich wrote:
> | > Andy Newman wrote:
> | > > But luckily there's only one array parameter
> | > >so the error is not that much of a challenge.
> | >
> | >
> | > um. you have not waded through the GNU ifdef hell, I'm guessing.
> |
> | Oh yes. Fun stuff.  I just love autoconf et al.  Nightmare time.
> | It's easier without it.  Here in Oz there was an old Sara Lee
> | ad... Layer upon layer upon layer...
>

Re: [9fans] GNU binutils: you can't make this shit up

[jmk]

Al Aho was enamoured enough by this comment to
consider using it in his new edition of the 'dragon book':

	% grep 'holy cow' /sys/games/lib/fortunes
	gcc is the holy cow of compilers, not the holy grail.  - forsyth
	% 

--jim

Re: [9fans] GNU binutils: you can't make this shit up

[Bruce Ellis]

al is a wise man, so is charles.

brucee

On 1/17/06, jmk@plan9.bell-labs.com <jmk@plan9.bell-labs.com> wrote:
>
> Al Aho was enamoured enough by this comment to
> consider using it in his new edition of the 'dragon book':
>
>        % grep 'holy cow' /sys/games/lib/fortunes
>        gcc is the holy cow of compilers, not the holy grail.  - forsyth
>        %
>
> --jim