Re: Capabilities
Conceptually this is how memory management works on post 8086 processors. The
8086/8 doesn't have any mechanism for trapping memory accesses, thus tables
are not possible.
--Perry
>
> 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
>
--
Perry Harrington Linux rules all OSes.APSoft ()
email: [EMAIL PROTECTED] Think Blue. /\
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: Technical question & boot problem
>I bet it definitely works (boot on XT drive) if one disables the onboard >IDE first. >The problem I see is using IDE and MFM/RLL drives at the same time, >which might prove difficult. To boot XT drives on an AT+, one usually has to disable the IDE drives so that the BIOS doesn't go looking there. XT controllers usually have an extension BIOS to hook into the main BIOS boot entry point.
Re: Technical question & boot problem
> could be the cause? As a hint: When I start dosemu with xdos -A it > complains that sector 1 could not be found. What does this mean? This is floppy prvbe. It attempts to seek sector 1 of track that doesn't exist on your floppy, fails and bail out, being sure that your floppy type is the one it probed for earlier. Check out the code to see what i mean, it has comments. bye, Ab
Re: Technical question & boot problem
On Thu, 10 Jun 1999, Dan Olson wrote: > > I've got a 808[68] maschine with a 40 MB harddisk with MS-DOS 3.3 > > installed. > > I want to use this maschine with ELKS in future so I decided to make a > > backup of the disk first. Can I just move the whole disk with it's > > adapter card to my Pentium? I noticed that there is a xt disk driver > > for linux. > > I suspect that this will probably not work...but you may be lucky. XT's > use jumpers or software on the card for determining hard drive parameters, > where all AT class machines have this in some sort of BIOS setup. If you > have a card which can be jumpered (I've got a couple like that) between XT > or AT you'll be alright. Also, if your Pentium has an IDE controller on > board, make sure you shut it off or it may conflict (though didn't xt and > at controllers use different interupts or something??). I'd say your best > bet is a 16 bit AT MFM controller card, that should work in your Pentuim > for sure. I bet it definitely works (boot on XT drive) if one disables the onboard IDE first. The problem I see is using IDE and MFM/RLL drives at the same time, which might prove difficult. Jakob
