Re: some docs needed

2000-08-07 Thread Alan Cox

 like system for 286. For this I would need some doc on very accurate
 doc on programming i286 in pmode and some doc on MinixFS (ok, I know almost

The Minix book covers the minixfs a bit. The 286 stuff I dont know good docs
on - they all seem to be discontinued. The pII downloadable manuals are very
patchy on 16bit protected mode




Re: A question

2000-06-20 Thread Alan Cox

 From what I understand, using the task struct to keep track of sleeping
 processes, limits the number of processes the kernel can handle. If you

In a sense since wakeup is O(N) by number of processes

 processes, you can increase functionality. If the number of sleeping
 processes is more then a certain number, you can activate the pointer and
 the kernel can follow the pointer like in a linked list. So you don't
 really use a linked list like linux does, but you use an array and when
 it's full, you can point to another array. 

For ELKS it isnt worth it. For real Linux it would be (and in fact it does
it all with lists)

 
 




Re: A question

2000-06-20 Thread Alan Cox

 various extended features (which few use) can then be easily added
 on a personal basis.  I doubt that ELKS has ever run more than 15
 processes, for instance.

For reference the standard V7 builds were for about 30-60 processes (60 being
a big box). 





Re: Definitive tree

2000-06-19 Thread Alan Cox

 and the source is now stored under CVS at sourceforge:
 http://sourceforge.net/project/?group_id=3232

I'll grab the sourceforget copy and probably send you diffs. (I dont have
the local bandwidth to fight cvs)

 Is this in some way related to your idea of moving the structure required from
 the kernel stack to the task structure?

Yes

Alan




Surgery On Linux 8086

2000-06-19 Thread Alan Cox


We have far too much ifdef crap. We appear to have more build options than
users. I've stripped out some of them in my tree (NOFS, SUID, CORE DUMP)
and I'll clean up more as I go so we actually have one OS not one OS each.

I've rewritten the wait queue code. We now do it sort of V7 style. You can
wait on one thing only (except for select see later)

current-waitpt

is the object you are waiting on (a waitqueue is now a char but could be
removed as a concept eventually). The kernel loops through each task (hell
we only have 30 or so ;)) and wakes those with matching ptr

If the pointer is to the select wait then we instead check if the object
we are waiting hashed into 16 buckets lands in a marked bucket. If so we
wake the task (and if the hashing is wrong it will sleep again). 16 may be
too low but 32 or 64 should work nicely

The kernel got smaller in the process and you no longer need a good computing
head to understand kernel/sleepwake.c

Alan



Re: Definitive tree

2000-06-19 Thread Alan Cox

 I've gotten pretty familiar with the linker, let me know if you
 need a hack.  Otherwise, my memory says that we've got enough
 info in the current header to put the stack below the data, providing
 the linker will change the beginning data offset to the max stack size.

We can already build binaries for this format. What we cant do is build ones
you can chmem.

I now have an ELKS that is a bit cleaner (not a lot), has my new wait queue
code working and I've written but not tested the back end for the swapper. It
needs someone strategy code and syscalls.  Right now only the bios driver
will get swapping right since I had to add req-rq_seg so I can swap stuff
without going via buffer cache - also means I guess we can write directly
from the L2 buffer cache.

Alan




Todays hacks

2000-06-19 Thread Alan Cox


[The full patch is 80K - who wants to check it in ?]

--- elks/CHANGELOG  Fri Mar  3 11:42:19 2000
+++ elks-ac/CHANGELOG   Mon Jun 19 23:52:08 2000
@@ -6,6 +6,31 @@
 Al
 --
 
+Mon Jun 19 29:39 GMT 2000   Alan Cox [EMAIL PROTECTED]
+
+   * Abolished the suid config option
+   * Merged stuff to reduce the ifdef clutter a bit
+   * Removed the nonexistant ip socket stuff. Its confusing having
+ all this old nonentity crap in it
+   * Buffer cache and request queue now have segment data
+   * Implemented segment stuff in the bios driver
+   * Added the back end code (untested so far) for swapping
+   * Replaced the wait queues with a V7 like wakeup mechanism
+ with a bit of auditing we should be ready to page kernel stacks
+ of sleeping processes that will free a fair bit of the data
+ segment at the same time as upping the task limit
+ - still need to get stacks smaller than 1K/task.
+   * Made select work using a crude hash and the V7 like wakeups. May
+ need a bigger hash
+   * Removed CONFIG_NOFS - just too ugly right now
+   * key_asm.S was dos line endings - fixed
+   * Cleaned up random #if 0 stuff
+   * Reformatted xt_key.c since it had bad tab/space damage
+   * Fixed incorrect comment about irqs
+   * Killed bh-b_prev for good
+   * Killed inode hash for good
+   * Make off_t signed as required by Unix and Posix
+   
 Fri Mar 03 11:44 GMT 2000   Alistair Riddoch  [EMAIL PROTECTED]
 
* Final changes for 0.0.83



Re: A question

2000-06-19 Thread Alan Cox

  Could anyone explain me what is a V7 like wakeup mechanism?

Old old unix systems took the address of the thing they wanted to wait on
and placed it in the task structure. Since the number of processes is pretty
low its easy for the CPU to walk the process table on a wakeup checking
if the 'wakeup' for this process matches the value it is given to wake.

Its low on memory usage, its simple and it works low end. Later Unixes
apparently started hashing them as the process sets got bigger, and Linux
uses linked lists of tasks waiting on an event - relatively memory
expensive but very clean and scalable - a good tradeoff for Linux a bad
one for ELKS








Re: Definitive tree

2000-06-18 Thread Alan Cox

 : I think I've figured how to
 : sort some of the stack handling stuff out and get some of our data space
 : back. 
 
 You're not thinking of backtracing stack addresses, are you?

No. Something much simpler. The idea being to get into a state where there
is nothing on the kernel stack needed when a task is not in RUN state.. ie
replacing the wait queue/select stuff with a V7 like setup.

User space Im very tempted to rebuild the system with the stack at the base
of the data segment, although that would prevent chmem working without
relocation maps on load. It trades it for the ability to truely grow process
space once you have swap

Alan





Re: ELKS to do?

2000-06-12 Thread Alan Cox

 for(i=0; i6; ++i)
 ;
 nosound();
 }
 
 which is way too long (5 seconds) for any 8086 I've ever used (or my
 Tandy's V-20). Is there something akin to bogomips that is tested by ELKS
 that can be used to set the loop to some processor speed dependent value?

Use the bogomips value for the loop should be about right IMHO




Re: Market space for a 16-bit linux product?

2000-06-09 Thread Alan Cox

 After all, there exists MINIX and open-source 11Kb kernels
 for microcontrollers with TCP/IP stack and all...

11K with tcp/ip - I've not seen that. 11K core oh and its 30K for TCP minimum
but we didnt tell you until you asked I have seen ;)




Re: palmtop OS

2000-05-11 Thread Alan Cox

  Anyone know if I can a get a UNIX-like OS on my PSION 5, does it 
  require a flash card for extra storage space?  (8meg...)

Linux is running on the 5 but not 5MX. You want a flash card for it. You also
want to think what your intended use is - the speed on those kind of devices
is not going to lend itself to compiling for example.

  or, is there a palmtop I can invest in that is beter for UNIX??

I ended up with a small PC. The old IBM PC110 was the smallest but as its 486
era it outlived its usefulness. I now have a palmax which is a bit bigger but
just about fits in a coat pocket. Others like the old Librettos 




Re: Re[2]: palmtop OS

2000-05-11 Thread Alan Cox

  actually, I am intending to use it for C programming (on the move...) 
  from CLI, cos its got a HUGE battery life and Im learning C.

Common misconception. It is designed to operate on a very low power level.
When you start needing high power levels its battery life is poor.

Alan




Re: ELKS and TCP/IP

2000-05-03 Thread Alan Cox

 is out there and ported to a micro or two. Only does PPP though.
 It appears to be derived from KA9Q, BSD and Linux code. I think the site
 is http://www.ucos-ii.com/

KA9Q is $50 a copy of non education/non amateur radio users

Alan




Re: elks

2000-04-29 Thread Alan Cox

 Then I am missing quite a bit of recognition of the early work in
 porting UNIX in the form of Minix by the group of Andy Tanenbaum.
 We still have the minix format around, but Andy was one of the
 first the throw open the full source code for Minix in his book:
 Operating Systems, Design  Implementation, PH, long before Linus
 Torwalds made it into a full, viable system.

And both Dave Braun and Steve Hosgood before him - and we keep finding
more of these. Its a good demo that the net wasnt good enough to support
such probjects

(UZI btw will run on a CP/M Z80 box)





Re: Location of ELKS Archive?

2000-04-26 Thread Alan Cox

 Looking at the state of the project it is no longer obvious to me which way to
 proceed. It essentially runs pretty stably on all my test platforms, and I
 have reached the point where it is no longer obvious to me what to do next.
 
 Any ideas anyone?

Call it 0.99 announce it and go on holiday is I believe Linus approach 8)

Basically it works. 

Alan




Re: Location of ELKS Archive?

2000-04-26 Thread Alan Cox

 Does this mean ELKS has TCP/IP networking with PPP and/or SLIP?

Nope. Thats a totally seperate project



Re: Is ELKS a good idea for teaching O.S.

2000-04-09 Thread Alan Cox

 dosemu is enough for Elks. I did not try yet but it must be light and fast.
 If someone want to run Elks on non x86, then she need Bochs
 
 Also there is alternative of VMware is under development with GPL...
 http://www.plex86.org/ (it was called FreeMWare). I am expecting this...

Also usermode linux may be of interest once its a bit more stable

Alan




Re: ELKS for ARM

2000-03-01 Thread Alan Cox

  I have started porting ELKS for ARM.
  Is is somebody working similar project?

I believe there is a ucLinux ARM project for the 7500T. (ucLinux is full
Linux without an MMU)

Alan



Re: 8086/88 80286 ||| 80386 80486 Pentium ...

2000-02-29 Thread Alan Cox

 I have a 386 AND a 486 that I am unable to bring up on Linux because the
 current version requires more than 8 MB ram.  The setup that I want requires

No. The current Linux is fine in 4Mb. The distribution installers with all
their GUI garbage frequently require more. If you are trying to build
a distribution on a small box I'd suggest you borrow a Debian CD from
someone. Right now its the only major dist I know that will install sensibly
in 4/8Mb



Re: 8086/88 80286 ||| 80386 80486 Pentium ...

2000-02-24 Thread Alan Cox

 Do any one had a linux ported to Hitachi processor.can elks can
 be used
 for embedded systems is there any one who is intrested for a linux
 kernel
 development.

There is a standard linux port for SH3

Alan



Re: Interesting

2000-01-31 Thread Alan Cox

 1) Is ELKS qualified for Safety applications (Eg: Plant Temperature Control system, 
and is the Kernel development controlled by some body of members)

Right now ELKS is a 'hey it sort of works' piece of fun

 2) I have a 8088 based Industrial PC\XT board and is it possible to run Linux on it.

Maybe

 4) Is this ELKS formally distributed like RedHat Linux, SuSe Linux as a product or 
is it a free product.

Its just a couple of disks of free toys

 Electronics  Instrumentation Division
 Indira Gandhi Centre for Atomic Research, Kalpakkam.

Please dont run any atomic power stations on it just yet 8)



Re: KA9Q

2000-01-26 Thread Alan Cox

 that might be useable as a user-mode ELKS implmentation
 of IP, UDP and TCP.  And it supports alot of different cards

Not directly tho

 as well as serial.

KA9Q net was the earlier package, it ran on CP/M once so may fit



Re: May be mistake?

1999-12-28 Thread Alan Cox

if (irq  8) {
 cache_21 |= 1  irq;
 outb(0x21,cache_21);   --- outb(cache_21,0x21);
 } else {
 cache_A1 |= 1  (irq-8);
 outb(0xA1,cache_A1);   --- outb(cache_A1,0xA1);

Linux outb() macros are data, port 



Re: self-compile bcc?

1999-12-06 Thread Alan Cox

 I fully support that idea.  I've also got versions of libc-8086 and the
 minix libraries cross compiled, but the libc.a is too large for the
 ELKS file system, since ELKS has a filesystem implementation problem
 for any file  512k

Just fix the triple indirection and you can have 2Gig files I think 8)




Re: Microwindows/Nano-X version 0.87pre1 released

1999-12-02 Thread Alan Cox

 at extremely high speed.  Unlike the Xlib implementation, Nano-X still runs
 synchronously per client, meaning that once a client request packet is sent,
 the server waits until the whole packet has arrived until servicing another
 client.
 This keeps the server code immensely simpler, while still running very quickly.

That kills you on a network or a client hang at the wrong moment. Reblocking
the data isnt hard but it can be sorted later. The big thing with reblocking
in nanogui will be keeping the max command length low to avoid large buffers



Re: Some questions, esp. for Alan

1999-11-29 Thread Alan Cox

 need to be done once, and it would not be necessary to increment the
 refcount artificially. Could anyone with a good understanding of the fs
 code comment on this? I would particularly like to here what Alan thinks.

The refcount is bumped otherwise you may get a race when an inode is freed
by another user. 

 Secondly there are many places in the code where pointers are checked to
 see if they are NULL. Frequently the result is not fatal, but by inspecting

On the bigger kernel NULL is a valid getblk return for a block I/O error.
 



Re: Redhat Linux6.o for athlon

1999-11-29 Thread Alan Cox

 The Athlon should run Linux fine.  It doesn't have any optimizations from a kernel
 standpoint, but that'll come in time.

They are in 2.3.x. I have 2.2.x patches but they arent generally available.

 If you get an athlon, you're going to be paying for floating point performance,
 and not neccessarily everyday speed.  You can save yourself a tremendous amount of
 money by purchasing a Celeron 550, that'll whoop a p3 550, sans coppermine.

The Athlon is faster on both integer, memory bandwidth and fpu, but a celeron
isnt that much slower and is a lot cheaper.



Re: Intro

1999-11-17 Thread Alan Cox

 development environment with an embedded OS.  In order to do this I must
 add SLIP  PLIP to ELKS, I would like to get in contact with the
 relevant ppl to find out what is being done, and what needs to be done
 on the networking layer.

We dont really have a networking layer. I don't that is in itself a problem
since you can prove you send/receive frames correctly and the rest is someone
elses problem. There are some ideas for the stack kicking around. One thing
for sure. The stack will be a userspace app.

 Also if anyone has any ideas on getting an EEPROM to boot on an old 8086
 laptop, I would be greatfull :)

Develop using DOSemu on Linux. It saves that annoying reboot cycle, and you can
use the DOSemu ioport logging to debug it ;)



Re: Linux on 486 without fdd/hdd

1999-11-13 Thread Alan Cox

 In my proposed setup I don't have hdd/fdd. I am just having CDROM drive
 and 16MB RAM, 486 PC. I am interested in booting linux from CDROM and run
 a browser like Netscape from the same CD. 

Wrong list. This list is for Linux on 286 or lower CPU machines

Alan



Re: ELKS - init

1999-11-10 Thread Alan Cox

 one more thing: the `date.c' does nothing about setting the date.  can we
 use anything else than BIOS calls to do that?

If the machine has a CMOS clock (note XT's dont generally have this) you can
do it in userspace by hitting the I/O ports. Its not really worth putting
in kernel on such a small box.

Alan



Re: Linux 8086 TCP/IP stack options - anyone for 6502-C

1999-10-28 Thread Alan Cox

 I might be able to take a look, it has been a while since I did any 6502
 assembly, but ...
 
 BTW is their any reason why we don't do a full re-implementation. It can't
 be that bad.

If you want to write one from scratch sure go ahead and do it. 

Alan



Re: Stability

1999-10-28 Thread Alan Cox

 The only reason I suggested using 0.1 as the stable tree is because we are
 currently heading towards making 0.1.0 a stable version.

Well we've never applied any idea of stable/not before 1.0 to mainstream
Linux. I think tradition is 0.x = unfinished

Alan



Re: Getting ELKS

1999-10-28 Thread Alan Cox

 drive.  The processor is  a  NEC V20.   I would like to use the machine
 for something other than a oversized door-stop.

You could saw it in half and use it as too suitable size doorstops ?

   1) Will ELKS work on this machine?

It tends to use the BIOS so probably

   2) What do I need to download to  get the entire ELKS package
 (including an Xwindow environment package)?

You are unlikely to ever see X on a machine that prehistoric. THere is a gui
in early development.

   4) What, if any, documentation is available?

Very little. This is at the "my god I installed to hard disk and its still
there" stage system.

   5) What is the current state of interconnectivity in ELKS (ie:
 ppp, terminal emulator, TCP/IP, etc...)

terminal emulation should work. No ppp or tcp/ip

Alan



Linux 8086 TCP/IP stack options - anyone for 6502-C

1999-10-26 Thread Alan Cox

 Also, on another note, in catching signals in Linux from the terminal
 emulator, I attempt to send them to the process group with killpg().
 This routine under ELKS causes an undefined symbol getgpid() when
 linking.  It appears there's an error in linux-8086 libc.

That should be getpgrp() I think


I've been rummaging around following some leads from from Kira on Linuxnet
and now we need to find someone who wants to do 6502-C conversions or
Z80-C conversions (the 6502 one looks the best)

Phil Blundells 6502 TCP/IP stack - http://www.tazenda.demon.co.uk/phil/iprom.S
On the Z80 side there is http://www.altsoft.demon.co.uk/cpcip/ which seems
to have a long way to goon TCP (the hard bit)

The 6502 one is interesting cos Phil Blundell appears to be the same one as
the Linux guy so hopefully we can get it GPL'd

Alan



Re: Licensing summary

1999-10-05 Thread Alan Cox

 I disagree.  If a vendor can take the proprietary route, he probably will.

That doesnt back up experience. The only vendor who wants to take a proprietary
route is one for whom this is 'core technology'. To everyone else its overhead
and overheads want reducing so you make more profit on the product.

 BTW, the MPL has a serious flaw in that you can avoid contributing stuff
 back to the project just by putting it in a separate file.

Same with the LGPL, you just put it inside or outside the library.

 



Re: Request for comments - Microwindows

1999-10-05 Thread Alan Cox

 Actually, the BSD and X licenses best reflect the needs of embedded
 developers.

The X one does. The BSD original format doesnt. The advertising clause got
a netbsd router project by a very large networking company canned



Re: Request for comments - Microwindows

1999-10-04 Thread Alan Cox

   So even though David Bell said "Permission is granted to use, distribute,
 or modify this source, provided that this copyright notice remain intact" we
 can say that now his code is subject to another agreement, the LGPL?
 Doesn't the LGPL restrict more than the above?

Yes. But that is allowed. 

You can take his work and use it as allowed by his license to create a
derivative work - his license allows this. What you cannot do is stop someone
taking David Bell's original work and using it under David Bell's license 
alone.

The derivative work (the combination) is differently licensed to the original
code he wrote.

 Also, can we have a GPL license on the server and an LGPL license
 on the applications?  Can we have both even if we allow linked-in
 apps and client/server apps?

It gets complicated in the linked in case.

Alan



Re: Request for comments - Microwindows

1999-10-04 Thread Alan Cox

 people will be able to hide drivers from us, as I think this has the 
 potential to seriously injure Micro*'s open-source value. 
 
 So has the lack of support for on devices where specs simply aren't openly
 available.

In the longer term XFree86 has gained by the fact vendors wont ship binary
only kit. Its now at the point that 'Linux' is a question big vendors ask
and that 'no' costs you bulk sales



Re: Request for comments - Microwindows

1999-10-04 Thread Alan Cox

  In the longer term XFree86 has gained by the fact vendors wont ship binary
  only kit. Its now at the point that 'Linux' is a question big vendors ask
  and that 'no' costs you bulk sales
 
 I don't understand.  What do you mean?

"I want to make Linux support an XYZ card"
"Im sorry we only allow binary drivers"
"oh goodbye"

[nowdays]

"Hi majorvendor foo purchasing here we want to source 50,000 XYZ cards"
"Oh great yes, expenses paid lunch coming right up"
"We do want Linux support as we may be certifying our stuff for Linux"
"Oh.. umm. I need to talk to the boss"

And vendors are changing policy for these kind of reasons



Re: Stupid licensing thread (Was: Request for comments - Microwindows)

1999-10-04 Thread Alan Cox

 As long as the API and/or messaging protocol are open spec, then anyone 
 can write their own library.  X is an example, XFree uses opensource 
 license, metrox and accelx used closed.  Same function, same result, but 
 they had to write their own library. 

[Equally a server]

 Actually they wouldn't have had to if they didn't want to. The XFree license
 permits closed source use.

Indeed. And while LGPL might be better in some ways than the BSD license X
wouldnt be where it is today had it had a GPL library



Re: Another ELKS idea for shared libraries

1999-09-28 Thread Alan Cox

 : for task switching), can bcc handle that?  Or create something like an 
 : indirect jump and glue code in the library.
 
   The indirect jump and glue code is exactly what is needed out of bcc.
 currently, it doesn't generate any of that kind of code.

It also cant do that on an 8086 without ruining swapping/defrag



Re: Another ELKS idea for shared libraries

1999-09-28 Thread Alan Cox

   As I mentioned before, if this were performed with code segments
 only, then they could still be shared with the resulting memory decrease benefit.

But is outweighed by the cost of no swapping or defragmentation

   In fact, with a ridiculous increase in code size, all absolute
 locations could use a [bx] register offset to get to a small table of hard
 adresses, just like the ELF .got section is implemented.  I'm not recommending
 this, though, since we're already short on cseg space.

You need to cover call/ret sequences. It is doable but hard



Re: there's still life in the Z80

1999-09-23 Thread Alan Cox

  http://www.zilog.com/ez80/
  
 
 Someone now design a cool linux box with the ez80. 
 Would it be possible as it has a MMU and supports 16mb of memory ?

You'd need to get the compiler kit working first, but I guess so





Re: get compile error compiling objdump85

1999-09-08 Thread Alan Cox

 Basically, the time-honored FILE * constants stdin, stdout, and stderr are no longer
 constant.  The offending line is:

They've never been constants in all cases.

 done this?  It's going to screw up alot of old programs.

only broken ones as far as standards believe



Re: [fs/select] problem with get_user()

1999-08-30 Thread Alan Cox

 What is needed is a similar function, perhaps peekd() which
 would return a long. Then we could define a macro get_user_long()

You mean

unsigned long peekd(unsigned short *x)
{
return peekw(x)(peekw(x+1)8);
}



Re: 8051 or Z80 Can run ELKS

1999-08-21 Thread Alan Cox

 Does this include the 8051 8031 8751 etc?? Are there other linux or
 otherwise UNIX compatible embedded system OS that works in Z80 an 8051?

UZI runs on a Z80



Re: SIBO/Psion Elks

1999-08-16 Thread Alan Cox

 1). Reduced character size to 8x8 to increase screen size and save memory
 (the font is held in Data segment)

Can you not find the Psion font in rom ? Also you could push the font into
its own segment and 'borrow' ES momentarily with a cli around a single char
render.

 1). The current version of Init (in elkscmd) seems to need /var/utcp to be
 exist, what does this do and should this file be writable (which won't be
 possible with a read only file system!)?

Eventually you are going to need a ram disk.

 2). PS requires '/proc', but I can't see any code where this 'created'.

The mainstream Linux has a /proc we don't. The intention is to make /proc
dig around in /dev/kmem

 1). I still can't get Config #DEF's to link through to .S files for parsing.
 Is this working on other people's machines? (this is making life kind of
 difficult).

.S files should go via the C pre processor. .s files dont

 2). The build tree doesn't fully work with all the options. For example if
 you don't have loadable modules, 'sys_dlload' is not defined and causes a
 build error (have to then change the auto generated arch/xxx/kernel/entry.c
 file).

Yep. I noticed this. Thats a case of clean them up as you find them

 If someone could summarise what needs to be where and why (for a minimum
 system, remember I'm working with a 128K disk for the time being) it would

Absolute minimum you probably want init (hacked without /var/utmp if need be)
although this is optional. You want ash the shell (which can be your init)
and a few basic binaries.



Re: SIBO/Psion Elks

1999-08-16 Thread Alan Cox

   exist, what does this do and should this file be writable (which won't
  be
   possible with a read only file system!)?
  
  Eventually you are going to need a ram disk.
 [Simon Wood]  
 Why ???
 I agree that in a 'PC' type environment you will need disk storage, but
 there are many applications for ELKS that will not...
 
 In this specific case 'init' would need to create a RAM disk for /var before
 it continued booting - seems a suspect way of doing it to me.

Then you will need to do hacking otherwise - unix tools tend to assume disk
scratch space exists.

 And on this line in whinging 'clock' talks directly to hardware (which in my
 case doesn't exist!) - it should be through a clock driver!

No. The clock driver itself would take up valuable permanent space in the
kernel. It means you need the right clock binary for the hardware but it 
saves you kernel space. Linux 386 is a bit different but on an 8086 its best
in luser space

  .S files should go via the C pre processor. .s files dont
 [Simon Wood]  
 Yep I get the concept, but I can't get it to work :-(, how are the config
 #DEF's passed through Makefile to gcc?? (they certainly don't appear if you
 do 'gcc -dD').

It should be including the config header file.



Re: 8086 = 8057?

1999-08-15 Thread Alan Cox

   Are the 8086 instructions compatible with any intel
 microcontrollers such as the 8051, 8057 80257 MC80257 etc? If so, very

Not to my knowledge.

 cool linux machines with LCD displays and cheap MCUs can be build for the
 third world :) . Any ideas anyone??

Low end ARM chips like the 7110 have all the glue on board for LCD, ram
decode etc and are pretty cheap. They even have an MMU and run 'real' Linux



Re: cheep linux machines

1999-08-15 Thread Alan Cox

   ...away from the rest of the process, the bottleneck seems to be
 the machine layout... not the OS. I just cant seem to find a good list of
 all available mcus that run linux. the ARM website says nothing of the OLD
 ARMs like arm2/3, it starts with ARM6 which could be too much and too

ARM2/3 arent available any more. They haven't been for years. They need a ton
of glue logic. Age != pricing (in EU/US anyway)

 expensive. There has to be a website on the CHIPS not boards or machines
 that can run linux.. and the addition of (appx) pricing would be
 appreciated. Also does anyone know of intel MCUs like 8057 able to run
 8086 code?? That would bring the cost down to like 2.5$ :) .

The ones I know about

Running ELKS - so unfinished kernel as yet, but getting there, no networking
no MMU, small apps

801EC86 etc Embedded 8086 chips (Intel/AMD/...)

Some of these are very cheap. Psion sell a box using an embedded
x86 variant to end users for UKP100 (US$160) or so (the sienna) 
running their own OS (not linux)

Running UC/Linux - no MMU, strange libc
 
68451 "Dragonball" CPU - Motorola - as used in the palmpilot
heavily designed for low chip count PDA's

Running Real Linux

Cirrus ARM 7110 - 19MHz ARM7 CPU, on board lcd driver, gpio, ram
decode etc etc. Aimed at PDA's (used on Psion 5)

Motorola PPC - assorted chips mostly oriented to low chip count
communications tasks. ie CPU + 4xSCC + other logic

Mips- various chips but most vendors sell MIPS as a VLSI cell - 
  ie you do the chip design they integrate all the bits you
  want - high volume option only.

One of the real big issues with this is all the modern chips tend to use
advanced packaging techniques making them hard to build onto boards without
fancy tools.

Alan







Re: doa.org administrivia

1999-07-20 Thread Alan Cox

 Hi all,
 At 10:32am GMT, 18th July 1999, a host on the domain shared by
 doa.org was entered into the ORBS database.  As a result, some users have
 had mail bounce from the developers mailing list.  Any mail address which
 bounces to this list with an error such as the ORBS error, or a 'user does
 not exist' error will be removed from the mailing list.
 
 This is what happens when you use automatic mail rejection, it saves you 1
 spam a day and sends me 10 bounces a day.

It saves me 40 spams a day. It also encourages the admin of sites that are
a problem to fix them. Also orbs blocks specific hosts only. They dont block
a domain because of a single host



Re: Microwindows for Hercules

1999-07-18 Thread Alan Cox

   No need.  MicroWindows handles the Bresenham algorithm in the mid
 level code in devdraw.c.  It uses successive calls to drawpixel to make it work.
 In this way, people like you and me don't have to rewrite bresenham for every
 card someone wants

The code in devdraw.c is very naiive. It assumes pixel plotting is the underlyin
op. On many cards line slices are the underlying operation, horizontal or
vertical. What you probably want to do is generate a series of

draw_horizontal(x,y,l)

or
draw_vertical(x,y,l)

calls for most things

 This might be useful when bitblt is implemented though...

Having 32K of offscreen memory is always useful. 

Alan



Re: doa.org

1999-07-18 Thread Alan Cox

 The web message is not very friendly though!
 *shocked amusement*
 
 WEB PAGE CONTENT:
 GO AWAY, Your bugging me.

Indeed - terrible grammar ;)



Re: SV: herc microwin support

1999-07-18 Thread Alan Cox

 The source code for GEM desktop is AVAILABLE?! I've always wanted it!
 Where!!?!?!

Caldera released it , CP/M and some other oddments from the DR-DOS pile under
a no commercial use license.

CP/M is elegant code. CP/M 68K is really nice. GEM is just plain ick



Re: Psion ELKS Memory Mangament and Protection.

1999-06-10 Thread Alan Cox

Your summary seems pretty good. 

So its

384K base 
64K window
64K window
(junk)

The segment switching for ramdisks is a non issue. We are either writing to
the code or data segment, so you an do large I/O's to the window boundary
using one segment for the target and one for the source.

That only gets vaguely hairy when you want to allow a smaller program to
be running across a 64K boundary. The mm handling for that kind of 'aligned
as we need within any 64K block' is fun stuff.

Another amusement here is that if you are prepared to accept 56K as the 
maximum size for data, you can pull some very interesting stunts with the
kernel stacks, allowing for many more processes - and getting it to scale
per bank.

Basically you put kernel DS at

0x5000+8K
so it ends at
0x5FFF+8K 

Now you put the kernel stacks at DS:E000 and you have 16 kernel stacks per
bank. As your banks grow your number of stacks and thus processes go- indeed
most of the task struct can go here too with a bit of care. This is how
V7 works on a PDP11 using the 8K segments they had. The so called
'u area' is all the crap a process needs that isnt needed when it isnt 
running.

You'd need to change the wait queue code a little to handle this but not 
much.

The memory protection is crude, but will catch accidental errors easily. You
can't catch deliberate attacks on such a box so why try.

Now how do the SSD's work 8)

Alan




Re: z80 *ix...

1999-06-07 Thread Alan Cox

   Hey, recently a friend of mine mentioned something called UZI to me, which
 supposedly was/is a *ix for the z80, and ported to the z280.  Anyone else more
 familiar on it?

oak.oakland.edu:/pub/cpm/uzi



Re: Capabilities

1999-06-04 Thread Alan Cox

 A reloc table in the binary (like DOS EXE files) could work for code at
 least (as long as the binaries are immutable while a process is using
 them, and the programs are careful about self-modifying code).

No it doesnt

extern int foo1();

int foo2()
{
x=foo1;
x();
}

You need 32bit pointers and until you are in 286 mode you also need to do
basically impossible fixups






Re: Capabilities

1999-06-04 Thread Alan Cox

 Good points.  If we stayed restricted to large code segments only, however,
 then we could run much larger programs (like the bcc compiler, for one),
 if we restricted ourselves to the following:

bcc fitted in 64K on Minix built with ack so thats a BCC problem ...

   o Dont' swap code that has the multi-code segment bit set in the exe hdr.
 (This isn't that big a deal, especially if it lets us run real programs...)

Its a very big deal

   o Fork isn't a problem if we use shared code segments, and don't have
 far data pointers.

Thats the only bit I suspect is true



Re: Capabilities

1999-06-03 Thread Alan Cox

 : You then need a 386. 64K is the limit. The original work I did was designed
 : to be easy to run in 286 protected mode once you got rid of any BIOS interfaces.
 :
   Remind me - what then is the benefit of protected mode?  Merely
 separate address spaces?

You get two things in 286 protected mode

1.  You take exceptions if you try and go out of your segments
2.  You get 16Mbytes of addressable ram



Re: Capabilities

1999-06-03 Thread Alan Cox

 I was wondering if KA9Q NOS might be used as a basis for ELKS TCP/IP,
 rather than starting again from scratch...

$50 a copy to non education or amateur radio users. Unless that is Phil is
willing to change his licensing policy



Re: Capabilities

1999-06-03 Thread Alan Cox

   This brings up my wishlist again, that we should have bcc compiler
 support for medium and large models for x86.  Al Ridoch doesn't want to
 move to supporting the _far keyword.  I think that it would buy us alot, especially
 if we're going to stick with old outdated processors like the 8086.

Al is right however. Going to far screws you up totally on things like swapping
and makes fork truely horrible. Don't go that way except on a 286



Re: SV: Editor

1999-06-02 Thread Alan Cox

 'vi' is powerful? I think it looks kind of like EDLIN. Must scare a lot of
 people off, considering EDLIN's capabilities. I prefer editors like edit

vi is powerful. Powerful and usable are two often non-intersecting fields.

 How is the ELKS API accessed in assembly? I think I'll need that if I'm
 going to code one of those editors.

Its calls via int 0x80. Take a look at the C library source. You shouldnt
need any asm.

BTW if you want edlin there is a unix clone called 'deadlin' or 'dedlin'
somewhere



Re: ELKS video drivers...

1999-05-27 Thread Alan Cox

  On Mon, 17 May 1999, Greg Haerr wrote:
 1. IBM MDA.
 no graphics support...
  
  Umm, are you sure?  We used to run windows 3.0 on amber monochrome
  monitors at college.
 I am also unsure.
 Can someone with a clue speak up?

MDA is text only, Hercules is the mono graphics display



Re: nanoGui development

1999-05-05 Thread Alan Cox

 Why is that?  to keep the kernel smaller?  My initial idea matched with

Yes. And also because you may be restoring to another graphical app..




Re: GEM (WAS Re: vgalib)

1999-04-23 Thread Alan Cox

  The GEM code is neat, and it *is* GPL'd, so maybe we can play
  with it, but it's always more fun to write our own code than
  port. =)
 
 Sure, it's more fun, but if you port code, then you can actually get some
 sort of relatively fast turnover of applications.

GEM is btw pretty limited. You can't for example draw except to the top
window in most versions of GEM



Re: some questions

1999-04-14 Thread Alan Cox

 There is an ELKS port to the Z80 ? That sounds nice. Can you tell me more
 about it ? Would be great to run Linux on my beloved Z80 machines in my
 "Museum".
 
 Why is ist stopped ?

ELKS is too big for this - look at UZI (ftp://oak.oakland.edu/CPM) and
OMU (http://tallyho.bc.nu/~steve)

Alan



Re: 32 bit OS for ARM

1999-02-19 Thread Alan Cox

 The linux kernel is too large for embedded system.  We may no want a
 file system at all.  One way to do this is to implement the application
 as the init program called by the kernel after booting, or just find the
 place
 that opens and executes init and change it to run the application actually
 linked with the kernel.

Thats relatively easy to do with linux 2.2, You just call kernel_thread()
to run a linked in task instead of mounting an fs and loading fs code.

Alan



Re: ELKS development ideas

1999-01-25 Thread Alan Cox

 Also, your point about using bios to get memory from pmode
 would allow us to use a fancier scheme (like the existing linux kernel's)

On a 286 or higher the right answer is quite simply to run in 286 protected
mode - its not _that_ hard to do.

 in order to get other memory?  Or is that what the EMM specs are
 for?

EMM is what you need for 8086 - paged memory banks. Generally people used
loadable DOS drivers so you'd need to dismember those to see what they 
used for bank switches (or run them in DOSemu and log port accesses). EMM
as a banked disk cache, ram disk, swap is perfectly sensible

Alan



Re: [linuxce-devel] Re: Web browser ported to Microwindows

1999-01-17 Thread Alan Cox

 I have heard a lot of things about konqueror, and much of it is not really 
 good.
 I really cant tell, I haven't seen anything of it. Is it as good as the 
 developers
 say it is ?

Not in my opinion, but its also not as bad as some of the people who complain
about it make out either



Re: [linuxce-devel] Re: Web browser ported to Microwindows

1999-01-16 Thread Alan Cox

 Yes, I suppose it would be good news also, if only their browser was GPL (or
 some other genuinely free  open-source license).  However, AFAICT it is
 thoroughly proprietary.
 
 Maybe they will choose to contribute back to Microwindows.  However, since
 Microwindows isn't GPL (it's MPL) they have no obligation to do so.

For a small browser the new gtkhtml work is looking very promising as a core.
Its actually the KDE khtmlw widget (that nice fast but not full of js/java/..
kfm viewer) aka 'konqueror' redone into C with a lot more gui independance.

Once its stable as a gtk widget it seems a good basis for an html viewer
for Nanogui/microwindows.



Re: My embedded linux project

1998-12-30 Thread Alan Cox

 Chipsets?  I'm building custom hardware because I want to get away from 
 chipsets.  completely unnecessary for my task.  Plus, I'd have to go thru 
 the expense of developing a custom bios and its not worth it.

How much CPU power do you actually need. If you can lay your own high
speed boards out the Cyrix MediaGX is basically a two chip set
(socket 7 cpu with extras) and a 5520. You could then leave most of the
peripheral intefaces you don't care about (audio/video ...) unattached


Alan



Re: bcc under ELKS?

1998-12-12 Thread Alan Cox

 Yes, I know that IBM-PC is not a Mac and does not have all many registers 
 but ELKS does not use all of them anyway!  IIRC the ES register is not 
 used and thus can be used in much the same way.  Also, PC code is usually 
 riddled with Int calls so why not use something like this...

Once you implement memory defragmentation and swapping you can't just do
intersegment calls on an 8086, you can on 286 protected mode. Since playing
with per task LDT stuff on 286 pm is seriously unfunny the first time you
try it I'd strongly suggest getting the 64/64k limited stuff working on
an 80286 pm first