gmane.os.inferno.general

Compiled inferno and started emu on BeagleBone Black

Jason Catena — 2013-05-10T05:12:54

With these minor changes, I was able to compile Inferno and start emu, on
Ångström Linux on the new BeagleBone Black.

root< at >beaglebone:/usr/inferno# diff mkconfig~ mkconfig
17c17
< SYSHOST=Plan9 # build system OS type (Hp, Inferno, Irix, Linux, MacOSX,
Nt, Plan9, Solaris)
---
Nt, Plan9, Solaris)
24,25c24,25
< #OBJTYPE=386 # target system object type (eg, 386, arm, mips, power,
s800, sparc)
< OBJTYPE=$objtype
---
sparc)

root< at >beaglebone:/usr/inferno# diff mkfiles/mkfile-Linux-arm~
mkfiles/mkfile-Linux-arm
11c11
< AS= arm-gcc -c
---
14c14
< CC= arm-gcc -c
---
21c21
< LD= arm-gcc
---

root< at >beaglebone:/usr/inferno# diff emu/Linux/os.c~ emu/Linux/os.c
6a7

Re: Problem with Inferno compilation under newest Plan9 update

Charles Forsyth — 2013-05-09T20:10:00


So it seems. It's a bit of a nuisance. I'll see what can be done to fix it.

Re: Problem with Inferno compilation under newest Plan9 update

Gorka Guardiola — 2013-05-09T20:04:49

On Thu, May 9, 2013 at 9:28 PM, Pavel Klinkovský <pavel.klinkovsky< at >gmail.com



You need to recompile your libraries because the type of things have
changed.

G.

Problem with Inferno compilation under newest Plan9 update

Pavel Klinkovský — 2013-05-09T19:28:56

Hi all,

in last days there is an update of Plan9 including support of 21-bit runes.
It seems it disables the compilation of Inferno there:

8l  yacc.8 /usr/inferno/Plan9/386/lib/libbio.a
/usr/inferno/Plan9/386/lib/lib9.a -lc
dofmt: incompatible type signatures
2569e19(/usr/inferno/Plan9/386/lib/lib9.a(fullrune)) and
392d4f87(/386/lib/libc.a(dofmt)) for chartorune
_fmtcpy: incompatible type signatures
81c6a929(/usr/inferno/Plan9/386/lib/lib9.a(fullrune)) and
4639e9f7(/386/lib/libc.a(dofmt)) for runetochar
mk: 8l  yacc.8 ...  : exit status=rc 324: 8l 326: error

Is it really caused by the Plan9 update, or do I have something wrong
locally in my computer?

Thanks in advance.

Regards,

Pavel

Re: Inferno native as real-time os

Charles Forsyth — 2013-04-29T02:51:46



Except for drivers that might be legally limited because they were
developed for particular projects under NDA,
and except for experimental code or code we forgot to release, I don't
think there is anything explicitly excluded
from the open source tree.

Re: Inferno native as real-time os

Charles Forsyth — 2013-04-29T02:49:43

I'd only go so far as to say it's reasonably lean. Like Plan 9, it doesn't
(for instance)
offer any bounds on operations, including interrupt lock-out, and deadline
support
is currently limited. For real time systems, I think in terms of deadlines
and WCET.
Mind you, many ostensibly "real-time" commercial operating systems
I've seen don't do any of that either, and come with few guarantees.

It is, however, a reasonably respectable *embedded* OS.


On 28 April 2013 13:45, Oleksandr Iakovliev <yshurik-9wnLQIiZAfpWk0Htik3J/w< at >public.gmane.org> wrote:

Re: Inferno native as real-time os

Sergey Zhilkin — 2013-04-28T18:23:45

http://doc.cat-v.org/inferno/historical_documents/website/realtime

Hello!
Native Inferno OS may be. I think, that implementation of RT is not a part
of open-source kernel.
28.04.2013 16:53 пользователь "Oleksandr Iakovliev" <yshurik-9wnLQIiZAfpWk0Htik3J/w< at >public.gmane.org>
написал:

Inferno native as real-time os

Oleksandr Iakovliev — 2013-04-28T12:45:02

Hi Inferno folks,

I guess some time ago I saw some message that native Inferno OS is
actually real-time OS, can you please refresh does it really fulfill
these requirements of being RTOS? (soft or hard category) That's
something that would be very interesting for research I guess.

Re: GSoC 2013 'java on dis' project proposal for Infenro

john francis lee — 2013-04-27T16:10:12

Google wouldn't allow Luis Ángel Méndez Gort to work on his project because

    residents and/or nationals of Iran, Syria, Cuba, Sudan, North Korea
    and Myanmar (Burma), with whom we are prohibited by U.S. law from
    engaging in commerce, are ineligible to participate.

You are apparently allowed to participate, Dmitry, but ...

    Please also note that any residents of Argentina, Belarus, Brazil,
    Chile, Colombia, Kazakhstan, Mexico, Peru, Russia, and the Ukraine
    that participate in the program will not receive a t-shirt or any
    promotional items for their participation.

I notice that both or you are 'allowed' to have gmail.com accounts ... 
the better to spy on you, to read your and your correspondents' mail. I 
guess the .com doesn't really stand for .commerce of the 'ineligible to 
participate' or 'open to arbitrary discrimination' sort.

The only thing that puzzles me is why good folks like yourselves want to 
be associated with an outfit like Google?


On 04/27/2013 07:58 PM, Dmitry

Re: Compilation of native inferno

Pavel Klinkovský — 2013-04-19T13:18:55

Yes.



Oh, I see.



Clear, thanks for explanation and help.

However I still have some problem when linking 'ipc':
allocdbuf: incompatible type signatures fe4dafd0 (taslock.8) and
d933881c(/usr/inferno/Inferno/386/lib/libmemdraw.a(memopaque)) for _tas

I am going to check deeply...

Pavel

Re: Compilation of native inferno

Charles Forsyth — 2013-04-19T12:18:45


I think he's using Plan 9 to compile a native system. Actually, I see that
my
previous answer, although true, isn't the right answer. When compiling
native
Inferno under any system, you still set mkconfig to refer to the *host*
system
used for cross-compilation. In this case, SYSTARG should be Plan9, not
Inferno,
since you're compiling data2c for use on Plan 9, not Inferno.

The native kernel's own mkfiles then rearrange things when they import
mkconfig,
to select the right target for just the kernel.

Re: Compilation of native inferno

Charles Forsyth — 2013-04-19T11:45:57



That should be defined (as an empty macro function) by the relevant lib9.h,
as it is in my copy

Re: Compilation of native inferno

Oleksandr Iakovliev — 2013-04-19T11:30:51

Hi, yes, native (not hosted) should be compiled as before, but it
depends on hardware where you can execute it - drivers issues. Not sure
why your are pointing to Plan9, maybe you meant Plan9 "hosted"?

Compilation of native inferno

Pavel Klinkovský — 2013-04-19T10:40:08

Hi all inferno fans,

I have a question:
Is the native inferno still supported?

I tried to make it in Plan9 system, but the utils/datac2 compilation failed
because of missing 'setbinmode' function...

Thanks in advance for any response.

Pavel

Re: MacOS X Installation Steps/Issues

Pete Elmore — 2013-04-18T22:39:34

I had to patch Inferno a little:  http://debu.gs/entries/interlude-inferno-at-work

I didn't see any changes in the hg repo, but I've heard a fix is forthcoming.

Re: MacOS X Installation Steps/Issues

Oleksandr Iakovliev — 2013-04-18T18:33:30

To get the inferno for Mac OSX, it is enough these steps:
http://lynxline.com/lab-1-compiler/

On 2013-04-18 05:39 , Brian Vito wrote:

MacOS X Installation Steps/Issues

Brian Vito — 2013-04-18T03:39:31

I have tried installing Inferno on MacOS X, but I can't figure out what to
do based on the instructions at:

http://www.vitanuova.com/inferno/downloads.html and in the INSTALL file.

I've downloaded inferno-20100120.tgz and macosx-386-bin.tgz. I unzipped the
inferno distribution in $HOME and then replaced the MacOSX folder with the
one from macosx-386-bin.tgz. I then edited mkconfig so the SYSHOST=MacOSX.

If I then try to run makemk.sh, I get the following:

./mkconfig: line 33: /Users/_____/inferno/mkfiles/mkfile-MacOSX-: No such
file or directory

and then libregexp compilation fails.

Where do the pre-compiled binaries from macosx-386-bin.tgz come in? Do I
even need to be trying to run makemk.sh?

If someone could help me out with the right steps, or email me a zip file
of a fully-compiled/installed version of inferno on MacOS X (10.8), it
would be much appreciated.

Thanks,
Brian

Re: Arm port, used _div in loaded

Oleksandr Iakovliev — 2013-04-14T12:59:13

Well, that's purpose of these labs, as you can get serial to your arm,
u-boot there or similar, then you can do totally same step-by-step
following these labs (there are almost no RPi/bcm2835 specifics yet)

Re: Arm port, used _div in loaded

Dmitry Kabak — 2013-04-14T11:52:59

Hello,

I think that the trick here is to make the linker not to strip down _div
function, so we just mention it in the file in place where it can be never
called. Probably that function is located in libkern/div-arm.s, but I'm not
sure.

Actually, the topic of low-level inferno porting to arm is really
interesting for me, but I couldn't manage one of my projects like this
(porting inferno to Cirrus Logic EP7312 arm cpu), so keep up your work,
it's not the easy one!



2013/4/14 Oleksandr Iakovliev <yshurik-9wnLQIiZAfpWk0Htik3J/w< at >public.gmane.org>

Arm port, used _div in loaded

Oleksandr Iakovliev — 2013-04-14T10:49:49

Hi Inferno people,

I am doing now kind of labs documenting of process porting Inferno OS to
Raspberry Pi. There is a question about trick/hack with "_div" reference
that you can find in inferno/plan9 sources (l.s). I am interested what
it is, as I can not really find information about this hack and its
influence.

Thanks!

URL: http://lynxline.com/lab-11-_div-testing-print/

Re: GSoC Project idea proposal

Oleksandr Iakovliev — 2013-04-13T14:45:41

Interesting, but are there any principal archetecture restrictions that
for example llvm can generate the Dis byte-code? If such module for llvm
could be implemented then other languages can make a place onto the
inferno glade...

On 2013-04-13 00:43 , john francis lee wrote: