On Thu, 11 Feb 1999, Dan Olson wrote:
Huh? Not to open up a large can of worms here, but in my opinion the ONLY
reason for ELKS is for something fun for its participants to do. The
relative utility of 8086-class computers goes down every day.
If you don't like it, then get off the
Hello Leo,
Just a lurker with a question and idea...
Same here.
How big is the minix code (x86 not source)? If it is big (relative to a
_plain_ FAT) maybe the minix fs is not necessary? and memory could be
freed by simplifying the filesystem? I understand the many limitations of
FAT but
On Wed, 10 Feb 1999, Steve Drake wrote:
The reason I can see for ELKS is what first lead me to take an interest
in it -- the "E" in ELKS stands for "Embeddable."
For those looking for a free, open source, embeddable OS, check out:
http://www.cygnus.com/ecos/
It does require a 32-bit (or
[David Given:]
UMSDOS is h u g e. While it *would* make ELKS easier to use, it would most
likely use so much space you couldn't use it for everything. Remember you need
the UMSDOS, MSDOS and FAT modules to make it work. If you *can* fit it in,
it'd be wonderful; but I'd be surprised.
[Leo Cyr:]
Just a lurker with a question and idea...
How big is the minix code (x86 not source)? If it is big (relative to a
_plain_ FAT) maybe the minix fs is not necessary? and memory could be
freed by simplifying the filesystem? I understand the many limitations of
FAT but it appears
dg UMSDOS is h u g e. While it *would* make ELKS easier to use, it
dg would most likely use so much space you couldn't use it for
dg everything. Remember you need the UMSDOS, MSDOS and FAT modules to
dg make it work. If you *can* fit it in, it'd be wonderful; but I'd be
dg surprised.
ror4
Blaz Antonic writes:
Thinking in the bath last night I came up with a way of building user space
How romantic :-)
We create a meta driver called something like the user device driver which
has a whole load of generically named devices in /dev/udd0 -- /dev/uddn.
It is a nice idea
On Wed, 10 Feb 1999, Shane Kerr wrote:
On Wed, 10 Feb 1999, Steve Drake wrote:
The reason I can see for ELKS is what first lead me to take an interest
in it -- the "E" in ELKS stands for "Embeddable."
For those looking for a free, open source, embeddable OS, check out:
On Thu, 11 Feb 1999, [big5] ª÷©÷²z wrote:
The reason I can see for ELKS is what first lead me to take an interest
in it -- the "E" in ELKS stands for "Embeddable."
For those looking for a free, open source, embeddable OS, check out:
http://www.cygnus.com/ecos/
It does require a 32-bit
PROTECTED]] On Behalf Of David Given
Sent: Friday, 12 February 1999 00:52
To: [EMAIL PROTECTED]
Subject:Re: kernel fission was: msdos/umsdos support?
On Wed, 10 Feb 1999, Steve Drake wrote:
The reason I can see for ELKS is what first lead me to take an interest
in it -- the &q
what if the module had a list of function pointers at the begining of its
address space? then a snippit of org 0 asm code (well, actually just
data) could be used within each module to set up the pointers properly in
a 16 bit link, and the same asm stubs in the kernel would work for any
David Given writes:
[...]
We create a meta driver called something like the user device driver which
has a whole load of generically named devices in /dev/udd0 -- /dev/uddn.
[...]
while ((y = ioctl(x, UDD_WAIT_REQUEST, bar)) == 0) {
process_device_request(bar);
}
Just a lurker with a question and idea...
How big is the minix code (x86 not source)? If it is big (relative to a
_plain_ FAT) maybe the minix fs is not necessary? and memory could be
freed by simplifying the filesystem? I understand the many limitations of
FAT but it appears that elks is going
David Given writes:
what if the module had a list of function pointers at the begining of its
address space? then a snippit of org 0 asm code (well, actually just
data) could be used within each module to set up the pointers properly in
a 16 bit link, and the same asm stubs in the
#define DEVICE_NAME "sda"
struct udd_entry foo;
struct udd_request bar;
foo.type = UDD_BLOCK_DEVICE;
foo.name = DEVICE_NAME;
foo.no_minors = 5;
/* etc... */
x = open("/dev/udd", O_RDWR);
if ((y = ioctl(x, UDD_INIT_DRIVER, foo)) != 0) {
On Wed, 10 Feb 1999, Alistair Riddoch wrote:
I am very eneasy about going down any road that involves the use of far
pointers. The compiler is currently pretty stable, and the system is
getting there which is quite remarkable given that we have no real memory
protection. If we start adding
16 matches
Mail list logo
