Re: Capabilities
Greg Haerr writes: : Bcc. I think that its one of the things that needs porting the most. Why? : Here's why. : : ELKS is shaping up quite nicely. We have a useable unixish system. But I : think that it needs certain things: : : : A C compiler. I have had as a top priority getting the dev86 kit (bcc, as86, ld86) to run on ELKS ever since I first found ELKS. I have spent considerable hours enhancing the bcc compiler (it now compiles ansi without a preprocessor,) and have got all the dev programs to build and link using bcc. I also ported a small ar86 just for ELKS. On running them, there are a number of difficulties. As86 dies for lack of memory thru the brk() system call, which doesn't seem to work yet. In addition, back in January, when I did all this work, the ELKS kernel would corrupt the filesystem after any unlink(), and there was no fsck. So I gave up, ported bcc etc to minix, and started compiling it's libc. The unlink() problem is basically fixed I think. There is still a problem if you unlink processes that never terminate (like init). fsck is close to being ready. I will include it in the next version. ELKS now has come a long way, and I think that the filesystem works, fsck is available, and signals and pipes work, but we need people to run on it, and do stupid things that break things. I will volunteer to get all the tools self-hosting and produce a development distribution of them. : A nice(ish) way to install it. (ie, distribution) ELKS needs a distribution that allows the entire kernel and commands to be built, and then booted from, for hard disk usage. The chief maintainer, Al, only uses ELKS from floppy. We need more people testing ELKS using a standard command set compiled from scratch, and we need fsck in the distribution. Not entirely true. I do install to HD every now again, but find it a bit soul destroying as I crash so often it becomes unusable very quickly. In addition, the minix filesystem *must* support files 512k, something it doesn't do now. The libc.a file is 512k so you can't even link anything on ELKS. This requires supporting 7 indirect blocks. I will volunteer to fix the 512k block limit, but I'd like someone to build a standard distribution, that includes all commands and kernel and allows *everything* to be built from the top with one "make all". Okay, this is part of my overall goal, which I will be looking at overall. 'make all' will build all the binaries, make floppy will create a small filesystem suitable for booting from, and then you will be able to create packages which are tar files containing other binaries. In addition, being the chief nano-X contributor, I would like to see ELKS bundled with a nano-X distribution. I ported and maintain nano-X for ELKS, so I can help with this. : A decent text editor. Use levee for now, I've got a vi, but we need to actually try to use ELKS's filesystem, signals, and pipes before you'll want to edit anything for keeps. : Networking. I think we need ELKS DLL's for this, so that we can run the kernel and any user programs with separate code and data segments to keep the link size 64k. Al has done work on shared libraries, and I have some ideas more akin to Windows real-mode linking, but we need mods to the development tools for this. I'll do them if you want. : Romability. (I think I just invented a new word! 8*) : More standard unix commands. Please make a list of commands you want. It would be nice to list the commands we have, and what doesn't work with them. : Protected mode stuff. (With Expanded memory support). We're a ways off from this, but it'd be nice. I'd like to see support for 64k segments. : : : Some of these things will be difficult (if possible), but I think that : this is what we need to make it into a useable system. If people can use : the thing, then they are a lot more likely to work on it / test it. I totally agree. Pull down ELKS, and elkscmd, and compile them and run them and send comments to this list as to what works and what doesn't. Al said that he got signals working with the latest version, but I don't know what the number is or where to find it. The version that I last ran, 0.0.74, couldn't do "ls file" or "ls | more" without dying or breaking the file system. The default shell that root has when you log in is sash, which does not support any of the above. If you 'exec /bin/ash', you then have a decent shell with redirection and pipes which may work to an extent. I may now be time to make ash the default shell, but it does have licensing issues. Remember that you can get the latest CVS code either by checking out anonymously from the CVS server, or by downloading the daily snapshots. See section 4 of the FAQ for details. Al
Re: Capabilities
Greg Haerr writes: On Thursday, June 03, 1999 7:27 PM, Alan Cox [SMTP:[EMAIL PROTECTED]] wrote: :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 : : 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: I have not yet come across something I wanted to port that had too large a code segment, but enough data. Most programs don't port because they require so much data. bcc output is very compact. 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...) o Fork isn't a problem if we use shared code segments, and don't have far data pointers. We do currently share code segments very effectively. Al
Re: Capabilities
This sort of thing has been done under Windows (boundschecker) and I don't know if there's a regular Linux implementation of it... but thinking about it it's only practical for testing purposes since you're gonna take a pretty severe performance hit on even a P6-class machine, let alone an 8088. It also requires compiler work, and would either (a) bloat the assembly code, or (b) use CALL/RETs which are extrememely expensive on older chips. That said, if bounds checking existed under Linux and/or ELKS it would be very useful... just not something you'ld want to use in a production version. - Chad On Sun, 13 Jun 1999, Beau Kuiper wrote: About user-program protection: Why is this discussion continuing. Most programs are forever playing with memory and pointers because C works like that. To locate and verify every memory reference that a C program makes is simply stupid for the following reasons: 1) The code to do it will be unportable and complex, difficult to maintain, in assembly and most likely buggy too. This should be enough reason to scrap this idea. 2) It will be slow. Not your regular slow, not even windows 3.0 slow, I mean really, really SLOW! The performace hit may not be very noticable on a Pentium, but it will sure hurt the target processor, the 8088/8086 Beau Kuiper [EMAIL PROTECTED]
Re: Capabilities
I really don't see where this is a problem. User level processing does not need hardware memory protection; it could be implemented as a strictly software solution. For example, a table defined within the OS giving the user and the level. Then, all memory access could interrogate this table and give pseudo memory level security. And how are you going to make sure the program you are about to execute isn't going to do anything malicious ?? Rewrite kernel CS, DS, other programs' memory space, interrupt table or something else ?? By software control ??? How are you going to find out whether the binary you are attempting to run uses standard library calls or not (= uses some other code that violates system integrity) ?? Such code can be hidden in less than 50 bytes of code and covered pretty good. Any user can write ownprogram that allows him to rewrite important structures in memory (kernel DS) and thereby give him root access or just hang the system. bye, Ab
Re: Capabilities
About user-program protection: Why is this discussion continuing. Most programs are forever playing with memory and pointers because C works like that. To locate and verify every memory reference that a C program makes is simply stupid for the following reasons: 1) The code to do it will be unportable and complex, difficult to maintain, in assembly and most likely buggy too. This should be enough reason to scrap this idea. 2) It will be slow. Not your regular slow, not even windows 3.0 slow, I mean really, really SLOW! The performace hit may not be very noticable on a Pentium, but it will sure hurt the target processor, the 8088/8086 Beau Kuiper [EMAIL PROTECTED]
Re: Capabilities
I really don't see where this is a problem. User level processing does not
need
hardware memory protection; it could be implemented as a strictly software
solution. For example, a table defined within the OS giving the user and the
level. Then, all memory access could interrogate this table and give pseudo
memory level security.
==
Never cross a dragon - for you are crunchy and taste delicious!
My major interests are:
Amateur {Ham} Radio - N8MGU | Opera-Jazz-Musical Theater | Sailing | Judaica
- Original Message -
From: Perry Harrington [EMAIL PROTECTED]
To: Luke [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Thursday, June 03, 1999 9:11 PM
Subject: Re: Capabilities
In addition, the user programs could be protected from the kernel and
vice
versa...
Note, without memory protection we really have no lower priviledged users,
all users
are the equivelent of root. Users exist merely to provide some logical
division.
And that would be a big bonus, especially for embeded systems
Luke(Boo) Farrar.
--
Perry Harrington Linux rules all OSes.APSoft ()
email: [EMAIL PROTECTED] Think Blue. /\
Re: SV: Capabilities
Thor Harald Johansen wrote: The Psion 3a have a simple memory protection of a range of address that the program may write to, if a write outside these is attempted then an interrupt is trigger - I will probably attempt to use this once I have code. However it is possible for a malicious program (i.e. the stuff I have done so far) to defeat this. Well, can memory be protected at all on an 8086? -- Thor Harald Johansen [EMAIL PROTECTED] Not as such; the Psion hardware includes a rudimentary MMU. The processor is an NEC V30H. -- Matt J. Gumbley
RE: Capabilities
It seems like the answer to the protection problem is to write a virtual cpu to run under the kernal that would trap memory code, check it, then execute it it's self. Chris
Re: Capabilities
In message [EMAIL PROTECTED], Chris Hansen wrote: It seems like the answer to the protection problem is to write a virtual cpu to run under the kernal that would trap memory code, check it, then execute it it's self. If it is really for embeded systems, than it is no problems - usually embedded systems (with microcontrollers or DSPs) have no MMU or users or protected memory. These systems are supposed to be installed and thats it. bernd -- Bernd Petrovitsch Institute of Computer Technology Gußhausstraße 25-29, A-1040 Vienna Email: [EMAIL PROTECTED] "Der Horizont vieler Menschen ist ein Kreis mit Radius Null - und das nennen sie ihren Standpunkt." A. Einstein PGP signature
RE: SV: Capabilities
On Monday, June 07, 1999 8:43 AM, Thor Harald Johansen [SMTP:[EMAIL PROTECTED]] wrote: : No without a special added hardware. The I8086, 8088, 80188, 80186 : have no memory protection implemented. First chip from Intel which : has memory protection is 80286 as I know. : : If this is correct, the users in ELKS are just symbolic. Any program can do : what it wants, and every user with a program can get root access. BIG : problem. : -- : Thor Harald Johansen : [EMAIL PROTECTED] : That's why 286's and 386's were invented
RE: SV: Capabilities
Surely the point of ELKS is that it's an *embedded* Linux system (routers, settop boxen, etc), so even if multi-user is a possibility, it's not a major design feature, eh? And if we're sticking the netstack in userspace, this re-enforces the principle that "C2 compliant" multi-user environment is a secondary point. Let alone the programming nightmare a netstack in userspace presents to a coder fx:unfond memories of coding network daemons for BeOS, who's netstack is also in userspace I have to agree that in the interest of speed and code size that security isn't that important, and especially on an embedded system. My suggestion would be to use a 386 or other system is if that's really an issue, or maybe find a way to add memory protection to a special version of ELKs destened for the 286 (the 186 doesn't have memory protection as well, does it?). Dan
RE: Capabilities
On Mon, 7 Jun 1999, Chris Hansen wrote: It seems like the answer to the protection problem is to write a virtual cpu to run under the kernal that would trap memory code, check it, then execute it it's self. Chris That would be a very bad idea anyway. The performace hit would be at least 50% and people using embedded chips or 8086/8088 chips would suffer greatly for a unimportant cause. If security is an issue, then it is much more cost effective/wise to run Linux on a 386 or better processor. Th 8088 was never designed to provide memory protection, and the effect of trying to add it would result in much buggy annoying code that is unmaintainable, unworkable and unportable. My 5cents (we don't have 2c coins over in Australia) Beau Kuiper [EMAIL PROTECTED]
Re: SV: Capabilities
Well, can memory be protected at all on an 8086? No without a special added hardware. The I8086, 8088, 80188, 80186 have no memory protection implemented. First chip from Intel which has memory protection is 80286 as I know. Radek Hnilica Radek Hnilica E-mail: [EMAIL PROTECTED] http://www.linuxfan.com/~radek_hnilica
SV: Capabilities
The Psion 3a have a simple memory protection of a range of address that the program may write to, if a write outside these is attempted then an interrupt is trigger - I will probably attempt to use this once I have code. However it is possible for a malicious program (i.e. the stuff I have done so far) to defeat this. Well, can memory be protected at all on an 8086? -- Thor Harald Johansen [EMAIL PROTECTED]
Re: Capabilities
Well, can memory be protected at all on an 8086? I don't think so. Windows 2.0 could multitask DOS apps on an 8086, iff they were very well behaved. I've heard that the feture was pulled when stupid people tried to multitask things like 123. Ross
RE: Capabilities
In addition, the user programs could be protected from the kernel and vice versa... Note, without memory protection we really have no lower priviledged users, all users are the equivelent of root. Users exist merely to provide some logical division. [Simon Wood] Not 100% true, if a program behaves then the kernel can prevent inspection of privileged data. It's only when a program miss-behaves the trouble starts. FYI The Psion 3a have a simple memory protection of a range of address that the program may write to, if a write outside these is attempted then an interrupt is trigger - I will probably attempt to use this once I have code. However it is possible for a malicious program (i.e. the stuff I have done so far) to defeat this. Simon W.
RE: Capabilities
On Thu, 3 Jun 1999, Greg Haerr wrote: On Thursday, June 03, 1999 1:36 PM, Alex Holden [SMTP:[EMAIL PROTECTED]] wrote: : On Thu, 3 Jun 1999, Alan Cox wrote: : Keep networking mostly in user space. That btw is also the model things like : the early networking work on V7 unix took. : I was wondering if KA9Q NOS might be used as a basis for ELKS TCP/IP, : rather than starting again from scratch... That's a potentially very good idea. KA9Q is big, though, and needs compiler mods for bcc in order to fit in 64k. The individual parts are pretty compact. It's actually a multitasking kernel with TCP/IP, AX25, and SMTP, telnet, etc. all integrated together. If you could split it up into bits, it would probably fit within the limits. Though as Alan pointed out, the license is pretty restrictive (I had always thought it was without any restriction at all :). --- Linux- the choice of a GNU generation. -- : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham : http://www.linuxhacker.org/
RE: Capabilities
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Alex Holden Sent: 04 June 1999 10:38 To: Greg Haerr Cc: Alan Cox; [EMAIL PROTECTED] Subject: RE: Capabilities [ka9q] Though as Alan pointed out, the license is pretty restrictive (I had always thought it was without any restriction at all :). Her in the UK Demon Internet, http://www.demon.net/ distribute it free as their default connection method for DOS, unsure if it's the same KA9Q, if it's [free|share]ware or what, but that may be work investigating... I'm failry sure that there's a copy at ftp://ftp.demon.net/ for download (I could get exact info. if required) -TTFN, Darran
RE: Capabilities
On Fri, 4 Jun 1999, Darran D. Rimron wrote: Her in the UK Demon Internet, http://www.demon.net/ distribute it free as their default connection method for DOS, unsure if it's the same Cool, I didn't realise that. It must be a bit modified from the amateur radio one to be more useful for general Internet access. One problem with it is IIRC, NOS itself doesn't have a http server or browser, but several of the derivatives like JNOS do, which you could probably port back. KA9Q, if it's [free|share]ware or what, but that may be work investigating... I'm failry sure that there's a copy at ftp://ftp.demon.net/ for download (I could get exact info. if required) It wouldn't let me log in. --- Linux- the choice of a GNU generation. -- : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham : http://www.linuxhacker.org/
RE: Capabilities
On Thu, 3 Jun 1999, Greg Haerr wrote:
I see. So the large code model is essentially implemented by combining
functions together in a 64k segment until no more functions can be
added, then starting another segment, with all functions being called
using full seg:offset addressing mode.
The large model uses far addresses for both code and data. Small uses
both near. Medium and compact (I think only the MS compilers did the
latter) were, I think, small code, large data, and small data, large code
respectively.
DOS supported all these by virtue of not supporting any of them. Swapping
or relocating processes makes this rather harder.
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).
Even with the data segment limited to 64k, the large code model would
solve a number of problems. In addition, it'd work on 8086's and 286's.
What about "anonymous" data, accessed through libc calls? The segment
address of the data could be stored in a known part of the processes'
address space and if the program had to be relocated, the kernel would
check regs.{ds,es} and update them as necessary.
This would require said libc calls to observe some quite strict
restrictions, (never put the segment address into a "normal" register, for
example) but should otherwise be adequate.
Matthew.
Re: TCP/IP, KA9Q, etc. (was Re: Capabilities)
Alan Cox wrote: I didn't think it had any restrictions either... there are hundreds of different versions so it seems... Very few people realise it, but it is charged for, or $10K for a once off OEM license. And people pay the $10K for it to build small routers be easier to use the model in Doug Comer's books (since they're well documented, and there are no restrictions (as far as I could tell)) - The copyright on the book ? Argh, now you've got me rather worried Haven't got my copy here at hand, but I've read a book review (http://www.anatomy.usyd.edu.au/danny/book-reviews/h/Internetworking_with_TCP_IP_2.html) that says: "...using it does have a couple of advantages. One is that it is possible to print (and make available for ftp) the complete source code without copyright problems..." The book's software is downloadable from: http://www.cs.purdue.edu/homes/dec/netbooks.html That page even says that the book is "Ideal for implementors". I'll have to check the book's actual text to see if there's anything legal I should take care of... the last thing I want is Prof. Comer's lawyers on my back. God/insert deity of choice here bless the Free Software Foundation... -- Matt J. Gumbley, Software Engineer | Enigma Data Systems Ltd. Email: [EMAIL PROTECTED]| Chelsea House, 8-14 The Broadway, Tel: +44 (0)1444 476500 | Direct: | Haywards Heath, West Sussex. Fax: +44 (0)1444 476501 | 476510 | RH16 3AP England.
Re: Capabilities
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
On Friday, June 04, 1999 5:28 AM, Alan Cox [SMTP:[EMAIL PROTECTED]] wrote:
: 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
:
Good point, again. Per my last email, the compiler doesn't have to support far
proc ptrs though.
:
:
:
:
RE: Capabilities
On Thursday, June 03, 1999 7:27 PM, Alan Cox [SMTP:[EMAIL PROTECTED]] wrote: : 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 : : 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: 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...) o Fork isn't a problem if we use shared code segments, and don't have far data pointers. Greg
Re: Capabilities
On Thu, 3 Jun 1999, Alan Cox wrote: In addition, the minix filesystem *must* support files 512k, something it doesn't do now. The libc.a file is 512k so you can't even link anything on ELKS. This requires supporting 7 indirect blocks. Umm it used to. What happened ? : Networking. I think we need ELKS DLL's for this, so that we can run the kernel and any user programs with separate code and data segments to keep the link Keep networking mostly in user space. That btw is also the model things like the early networking work on V7 unix took. The networking text file in the Documentation dir says: Cut here 8 Notes on networking code Current development model is based around using a user process to be the actual TCP/IP stack with socket file descriptors and device drivers dealt with by the kernel. The diagram below show how things should work. ___ | | || |Network Application| |TCP/IP stack process| |___| || | / | | /| _|_/_| | |/ || | KERNEL | / || |_|__/_ __|| | | | | | | | | Socket code | | RAW Driver| | | |__| |___| | | || | || |_|| | __| | | | Network Hardware | |___| The Network Application uses the standard BSD socket interface to open and read and write to sockets. The socket code passes the data on to the TCP/IP stack process, through a file descriptor. (char device or socket). The TCP/IP stack process then constructs TCP/IP packets and writes them to the network device driver including all the necessary hardware headers. Cut here 8 This seems sane. If we have a /dev/ip to communicate with the tcp/ip stack process from the inet_ functions, then virtually everything sits outside the kernel. I don't know much about the userspace device drivers yet, but these could potentially be used for network drivers, and if not a network driver wouldn't take up too much memory. So the user space tcp/ip stack would just take the data, slap in in a cutesy little packet, and shove it out to the network driver (and the same but backwards). Something that shouldn't be as hard to do from userspace. I'll link my inet_ functions up to a device driver for now. Any comments? Lukeboo Farrar.
Re: Capabilities
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
On Thursday, June 03, 1999 6:01 AM, Alan Cox [SMTP:[EMAIL PROTECTED]] wrote: : In addition, the minix filesystem *must* support files 512k, something it :doesn't do : now. The libc.a file is 512k so you can't even link anything on ELKS. This : requires supporting 7 indirect blocks. : : Umm it used to. What happened ? I don't know. If you look at the 0.0.74 source, it flat out compares the indirect blocks to 7 and errors if greater... It doesn't look like the original code ever worked. I was quite concerned myself when I first looked at the code. After comparing it with the linux 386 sources, I felt it would be better to re-port from scratch, actually. It appears the ELKS fs is munged to accomodate a changed buffer system. : : : Networking. : : I think we need ELKS DLL's for this, so that we can run the kernel and : any user programs with separate code and data segments to keep the link : : Keep networking mostly in user space. That btw is also the model things like : the early networking work on V7 unix took. I like that idea. : : : Protected mode stuff. (With Expanded memory support). : : We're a ways off from this, but it'd be nice. I'd like to see : support for 64k segments. : : 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? Greg
Re: Capabilities
: 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
On Thu, 3 Jun 1999, Greg Haerr wrote: : : Protected mode stuff. (With Expanded memory support). : :We're a ways off from this, but it'd be nice. I'd like to see : support for 64k segments. : : 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? And a full 16Mb(!) of address space. Matthew.
RE: Capabilities
On Thursday, June 03, 1999 10:07 AM, Alan Cox [SMTP:[EMAIL PROTECTED]] wrote: : : 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 : : So, basically, 286 protected mode still runs in 64k segments, and in order to address the additional memory on a per-process basis we need large code or large data segments through the compiler (far pointers). In this way, larger programs can be written. With bcc currently, there would be no benefit to the size of user programs run, just more could be run on ELKS, since ELKS could allocate more physical memory by allocating more DS descriptors covering physical memory... In addition, the user programs could be protected from the kernel and vice versa... Right? Greg
Re: Capabilities
Greg: You might find http://www.x86.org/articles/pmbasics/tspec_a1_doc.html an interesting read on Protected Mode Basics. John O Greg Haerr wrote: On Thursday, June 03, 1999 10:07 AM, Alan Cox [SMTP:[EMAIL PROTECTED]] wrote: : : 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 : : So, basically, 286 protected mode still runs in 64k segments, and in order to address the additional memory on a per-process basis we need large code or large data segments through the compiler (far pointers). In this way, larger programs can be written. With bcc currently, there would be no benefit to the size of user programs run, just more could be run on ELKS, since ELKS could allocate more physical memory by allocating more DS descriptors covering physical memory... In addition, the user programs could be protected from the kernel and vice versa... Right? Greg
RE: Capabilities
On Thu, 3 Jun 1999, Greg Haerr wrote: On Thursday, June 03, 1999 10:07 AM, Alan Cox [SMTP:[EMAIL PROTECTED]] wrote: : : 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 : : So, basically, 286 protected mode still runs in 64k segments, and in order to address the additional memory on a per-process basis we need large code or large data segments through the compiler (far pointers). In this way, larger programs can be written. With bcc currently, there would be no benefit to the size of user programs run, just more could be run on ELKS, since ELKS could allocate more physical memory by allocating more DS descriptors covering physical memory... In addition, the user programs could be protected from the kernel and vice versa... And that would be a big bonus, especially for embeded systems Luke(Boo) Farrar.
Re: Capabilities
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
On Thursday, June 03, 1999 5:01 PM, Alan Cox [SMTP:[EMAIL PROTECTED]] wrote: : in order to address the additional memory on a per-process basis we need : large code or large data segments through the compiler (far pointers). In this : : There are no "large" segments. This is one of the horrors of 286 mode. A far : call is a segment:offset call. So you have multiple small segments this way. : I see. So the large code model is essentially implemented by combining functions together in a 64k segment until no more functions can be added, then starting another segment, with all functions being called using full seg:offset addressing mode. Even with the data segment limited to 64k, the large code model would solve a number of problems. In addition, it'd work on 8086's and 286's. Greg
RE: Capabilities
On Thursday, June 03, 1999 1:36 PM, Alex Holden [SMTP:[EMAIL PROTECTED]] wrote: : On Thu, 3 Jun 1999, Alan Cox wrote: : Keep networking mostly in user space. That btw is also the model things like : the early networking work on V7 unix took. : : I was wondering if KA9Q NOS might be used as a basis for ELKS TCP/IP, : rather than starting again from scratch... : : That's a potentially very good idea. KA9Q is big, though, and needs compiler mods for bcc in order to fit in 64k. 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. Greg
Re: Capabilities
In addition, the user programs could be protected from the kernel and vice versa... Note, without memory protection we really have no lower priviledged users, all users are the equivelent of root. Users exist merely to provide some logical division. And that would be a big bonus, especially for embeded systems Luke(Boo) Farrar. -- Perry Harrington Linux rules all OSes.APSoft () email: [EMAIL PROTECTED] Think Blue. /\
Re: Capabilities
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
SV: Capabilities
But seriously... I'm wanting to get my C skills back into shape. Can anyone think of a good program to port? Maybe "ed" wouldn't be such a bad start... or maybe some old games from Slackware's Y package... 'ed' already exists for ELKS. -- Thor Harald Johansen [EMAIL PROTECTED]
RE: Capabilities
My wife is currently addicted to Sokoban, how as ASCII version of that. Simon Wood Hardware Engineer Pace Micro Technology plc Victoria Road, Saltaire, Shipley West Yorkshire, BD18 3LF Tel : +44(0)1274 532000 Fax: +44(0)1274 532029 This E-Mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender. But seriously... I'm wanting to get my C skills back into shape. Can anyone think of a good program to port? Maybe "ed" wouldn't be such a bad start... or maybe some old games from Slackware's Y package...
Re: Capabilities
On Tue, 1 Jun 1999, Chris Starling wrote: Why would anyone want to use any editor other than vi? I'm almost done with the EMACS port. :) But seriously... I'm wanting to get my C skills back into shape. Can anyone think of a good program to port? Maybe "ed" wouldn't be such a bad start... or maybe some old games from Slackware's Y package... Bcc. I think that its one of the things that needs porting the most. Why? Here's why. ELKS is shaping up quite nicely. We have a useable unixish system. But I think that it needs certain things: A C compiler. A nice(ish) way to install it. (ie, distribution) A decent text editor. Networking. Romability. (I think I just invented a new word! 8*) More standard unix commands. Protected mode stuff. (With Expanded memory support). Some of these things will be difficult (if possible), but I think that this is what we need to make it into a useable system. If people can use the thing, then they are a lot more likely to work on it / test it. Luke(Boo) Farrar.
RE: Capabilities
On Tuesday, June 01, 1999 2:07 PM, Alistair Riddoch [SMTP:[EMAIL PROTECTED]] wrote: : Ross Vandegrift writes: : : Tell me of another editor. :) : : : You're not going to like your more reasonable options, but I'll be blunt: vi : or ed should work nicely, when ported. : : : Why would anyone want to use any editor other than vi? : : Al : ZZ : I can't understand why anyone would want an editor other than vi. So - I have source to a vi look-alike that I've ported to various opsys's including NT if you just can't stand it any longer... gh
RE: Capabilities
On Tuesday, June 01, 1999 7:19 PM, Ross Vandegrift [SMTP:[EMAIL PROTECTED]] wrote: : But seriously... I'm wanting to get my C skills back into shape. Can : anyone : think of a good program to port? Maybe "ed" wouldn't be such a bad : start... or : maybe some old games from Slackware's Y package... : : : ed would be a good start, but I'd rather see a vi implementation. When a : Un*x has vi, it can finally be called an OS ;-). Along the Y package, how : about the fortune program? It's cute, it's funny, and it shouldn't be too : difficult. : : Ross : Send me the source to fortune, I'll port it. gh
Re: Capabilities
Greg Haerr writes: On Tuesday, June 01, 1999 2:07 PM, Alistair Riddoch [SMTP:[EMAIL PROTECTED]] wrote: : Ross Vandegrift writes: : : Tell me of another editor. :) : : : You're not going to like your more reasonable options, but I'll be blunt: vi : or ed should work nicely, when ported. : : : Why would anyone want to use any editor other than vi? : : Al : ZZ : I can't understand why anyone would want an editor other than vi. So - I have source to a vi look-alike that I've ported to various opsys's including NT if you just can't stand it any longer... I am still trying to get hold of a vi clone that uses tmp files rather than keeping the file in RAM, and is GPL compatable. levee fails on both counts so is unable to deal with decent size files, and may cause license conflicts in elkscmd. Does your version fit these requirements? Al
RE: Capabilities
: I am still trying to get hold of a vi clone that uses tmp files rather than : keeping the file in RAM, and is GPL compatable. levee fails on both counts : so is unable to deal with decent size files, and may cause license : conflicts in elkscmd. Does your version fit these requirements? : : Al : My vi is Xvi, derivied from Stevie. It's license is looser than GPL, but I don't know about the file size stuff. Is this because we've got only 64k of data on ELKS?
RE: Capabilities
: Bcc. I think that its one of the things that needs porting the most. Why? : Here's why. : : ELKS is shaping up quite nicely. We have a useable unixish system. But I : think that it needs certain things: : : : A C compiler. I have had as a top priority getting the dev86 kit (bcc, as86, ld86) to run on ELKS ever since I first found ELKS. I have spent considerable hours enhancing the bcc compiler (it now compiles ansi without a preprocessor,) and have got all the dev programs to build and link using bcc. I also ported a small ar86 just for ELKS. On running them, there are a number of difficulties. As86 dies for lack of memory thru the brk() system call, which doesn't seem to work yet. In addition, back in January, when I did all this work, the ELKS kernel would corrupt the filesystem after any unlink(), and there was no fsck. So I gave up, ported bcc etc to minix, and started compiling it's libc. ELKS now has come a long way, and I think that the filesystem works, fsck is available, and signals and pipes work, but we need people to run on it, and do stupid things that break things. I will volunteer to get all the tools self-hosting and produce a development distribution of them. : A nice(ish) way to install it. (ie, distribution) ELKS needs a distribution that allows the entire kernel and commands to be built, and then booted from, for hard disk usage. The chief maintainer, Al, only uses ELKS from floppy. We need more people testing ELKS using a standard command set compiled from scratch, and we need fsck in the distribution. In addition, the minix filesystem *must* support files 512k, something it doesn't do now. The libc.a file is 512k so you can't even link anything on ELKS. This requires supporting 7 indirect blocks. I will volunteer to fix the 512k block limit, but I'd like someone to build a standard distribution, that includes all commands and kernel and allows *everything* to be built from the top with one "make all". In addition, being the chief nano-X contributor, I would like to see ELKS bundled with a nano-X distribution. I ported and maintain nano-X for ELKS, so I can help with this. : A decent text editor. Use levee for now, I've got a vi, but we need to actually try to use ELKS's filesystem, signals, and pipes before you'll want to edit anything for keeps. : Networking. I think we need ELKS DLL's for this, so that we can run the kernel and any user programs with separate code and data segments to keep the link size 64k. Al has done work on shared libraries, and I have some ideas more akin to Windows real-mode linking, but we need mods to the development tools for this. I'll do them if you want. : Romability. (I think I just invented a new word! 8*) : More standard unix commands. Please make a list of commands you want. It would be nice to list the commands we have, and what doesn't work with them. : Protected mode stuff. (With Expanded memory support). We're a ways off from this, but it'd be nice. I'd like to see support for 64k segments. : : : Some of these things will be difficult (if possible), but I think that : this is what we need to make it into a useable system. If people can use : the thing, then they are a lot more likely to work on it / test it. I totally agree. Pull down ELKS, and elkscmd, and compile them and run them and send comments to this list as to what works and what doesn't. Al said that he got signals working with the latest version, but I don't know what the number is or where to find it. The version that I last ran, 0.0.74, couldn't do "ls file" or "ls | more" without dying or breaking the file system. Greg : : : Luke(Boo) Farrar. : : : :
SV: Capabilities
Why on earth do you want pico? Apart from the fact that there's probably not enough tty support in the kernel yet, the Linux binary is 440k (without libc, ELKS needs to be static). So the answer is no, unless you remove all the functionality. Okay. I need a reasonably good text editor. Point me to one, please. ;) -- Thor Harald Johansen [EMAIL PROTECTED]
SV: Capabilities
Depends on the shell you're using - I believe sash doesn't implement pipes yet, but I'm not sure about the other shells... There are other shells? -- Thor Harald Johansen [EMAIL PROTECTED]
SV: Capabilities
Afaik pico is small enough. You can give it a try. Hm...someone claims it uses things that are not implemented in ELKS yet. Yes. Use ash. Where do I get it? Oh, by the way, the standard shell, is it very poor compared to other shells? Can I make ELKS boot from ONE disk instead of a boot + root disk? -- Thor Harald Johansen [EMAIL PROTECTED]
Re: SV: Capabilities
On Tue, 1 Jun 1999, Thor Harald Johansen wrote: Okay. I need a reasonably good text editor. Point me to one, please. ;) levee comes with the elkscmd package. Davey
Re: SV: Capabilities
On Tue, 1 Jun 1999, Thor Harald Johansen wrote: Oh, by the way, the standard shell, is it very poor compared to other shells? Actually, it's not, if you look at all it's doing. Sash as a shell is very basic, but internal to that one executable are a LOT of prorgams. From small programs such as cat, echo, cp, etc. up to ls, ed and tar. Can I make ELKS boot from ONE disk instead of a boot + root disk? Yes. Get the 'combo' disk image in the images.zip file. Davey
Re: Capabilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 31 May 1999, Thor Harald Johansen wrote: Is it possible to compile 'pico', the text editor, for ELKS? And does piping Pico is suprisngly large, it would probably be a lot more sensible to use a much smaller editor with more limited functionality. - - Aidan - -- http://www.skinner.demon.co.uk/aidan/ Real men whistle ed commands at 300 baud into a can. -BEGIN PGP SIGNATURE- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQA/AwUBN1NQvB1TS8W4wwL/EQIMogCg5mwi37i03xqRJwM5tZK6lgbxTm4An0mg nzn4+qascVETeD3YWQ9Wunot =RQv5 -END PGP SIGNATURE-
Re: Capabilities
On Mon, 31 May 1999, Thor Harald Johansen wrote:
Is it possible to compile 'pico', the text editor, for ELKS? And does piping
work ('', '|' and '') properly yet?
--
Thor Harald Johansen
[EMAIL PROTECTED]
Pico would be great, but is is part of Pine, the email program so it
wouldn't be as easy to port as you might think. But It would probably be
doable. I always use pico myself.
Luke(Boo) Farrar.
Re: Capabilities
On Tue, 1 Jun 1999, Aidan Skinner wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 31 May 1999, Thor Harald Johansen wrote: Is it possible to compile 'pico', the text editor, for ELKS? And does piping Pico is suprisngly large, it would probably be a lot more sensible to use a much smaller editor with more limited functionality. - - Aidan - -- How about a pico clone - It is pretty simple. Isn't it? Luke(Boo) Farrar.
SV: SV: Capabilities
levee comes with the elkscmd package. Do I just type 'leevee' after installing the package? -- Thor Harald Johansen [EMAIL PROTECTED]
SV: Capabilities
Pico is suprisngly large, it would probably be a lot more sensible to use a much smaller editor with more limited functionality. Okay. Point out one that works! -- Thor Harald Johansen [EMAIL PROTECTED]
Re: Capabilities
On Tue, 1 Jun 1999, Luke (boo) Farrar wrote:
On Mon, 31 May 1999, Thor Harald Johansen wrote:
Is it possible to compile 'pico', the text editor, for ELKS? And does piping
work ('', '|' and '') properly yet?
--
Thor Harald Johansen
[EMAIL PROTECTED]
Pico would be great, but is is part of Pine, the email program so it
wouldn't be as easy to port as you might think. But It would probably be
doable. I always use pico myself.
Luke(Boo) Farrar.
what about 'joe'. It is an excellent wordstar key based editor that may be
portable to ELKS. Several of the more eccentric features could be removed
if need be.
Beau Kuiper
[EMAIL PROTECTED]
SV: SV: Capabilities
Yes. Get the 'combo' disk image in the images.zip file. Can this image be used with the ELKS booter for DOS? -- Thor Harald Johansen [EMAIL PROTECTED]
RE: Capabilities
Might have a look at (older versions!) of joe. Originally a very simple wordstar clone, seems to have a BAD case of feeping creaturitis... -Original Message- From: Thor Harald Johansen [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 01, 1999 1:37 PM To: Luke (boo) Farrar Cc: [EMAIL PROTECTED] Subject: SV: Capabilities Pico would be great, but is is part of Pine, the email program so it wouldn't be as easy to port as you might think. But It would probably be doable. I always use pico myself. Tell me of another editor. :) -- Thor Harald Johansen [EMAIL PROTECTED]
Re: Capabilities
Tell me of another editor. :) You're not going to like your more reasonable options, but I'll be blunt: vi or ed should work nicely, when ported. Ross
Re: Capabilities
Ross Vandegrift writes: Tell me of another editor. :) You're not going to like your more reasonable options, but I'll be blunt: vi or ed should work nicely, when ported. Why would anyone want to use any editor other than vi? Al ZZ
Re: Capabilities
But seriously... I'm wanting to get my C skills back into shape. Can anyone think of a good program to port? Maybe "ed" wouldn't be such a bad start... or maybe some old games from Slackware's Y package... ed would be a good start, but I'd rather see a vi implementation. When a Un*x has vi, it can finally be called an OS ;-). Along the Y package, how about the fortune program? It's cute, it's funny, and it shouldn't be too difficult. Ross
Re: SV: Capabilities
Hi Thor. Depends on the shell you're using - I believe sash doesn't implement pipes yet, but I'm not sure about any other shells... There are other shells? I have heard rumours that there's a version of ksh working for ELKS, but I've never managed to track it down... Other than that, there's just the 'shell hacks' (as I call them), where somebody writes a C program that displays a menu on the screen, waits for a valid keypress, then executes whatever command has been associated with the relevant menu option by the programmer. If there are any ELKS shells other than those, and any reader of this email both knows of them and where to find them, YELL BY EMAIL!!! Best wishes from Riley. +--+ | There is something frustrating about the quality and speed of Linux | | development, ie., the quality is too high and the speed is too high, | | in other words, I can implement this feature, but I bet someone | | else has already done so and is just about to release their patch. | +--+ * ftp://ftp.MemAlpha.cx/pub/rhw/Linux * http://www.MemAlpha.cx/kernel.versions.html
Re: Capabilities
You're not going to like your more reasonable options, but I'll be blunt: vi or ed should work nicely, when ported. Why would anyone want to use any editor other than vi? ::Tactfully sidesteps impending religious war:: Is there a reason that I got two of this message? Ross
Re: Capabilities
On Tue, 1 Jun 1999, Ross Vandegrift wrote: ed would be a good start, but I'd rather see a vi implementation. ed, is called (surprisingly) ed. vi is called levee. Those 2 programs are already there in the elkscmd package. Davey
Re: Capabilities
On Tue, 1 Jun 1999, Alistair Riddoch wrote: Tell me of another editor. :) You're not going to like your more reasonable options, but I'll be blunt: vi or ed should work nicely, when ported. Why would anyone want to use any editor other than vi? Laziness. I invested an hour in /usr/doc/vim*/TUTORIAL and I'm much more efficient and portable for it. (Previously, I was ferrying Pico binaries around the various boxes we have here :) Matthew.
Capabilities
Is it possible to compile 'pico', the text editor, for ELKS? And does piping
work ('', '|' and '') properly yet?
--
Thor Harald Johansen
[EMAIL PROTECTED]
Re: Capabilities
Hi Thor.
Is it possible to compile 'pico', the text editor, for ELKS?
No idea, sorry.
And does piping work ('', '|' and '') properly yet?
Depends on the shell you're using - I believe sash doesn't implement
pipes yet, but I'm not sure about the other shells...
Best wishes from Riley.
+--+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+--+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html
