> -gnumach/i386/i386/fpe_linkage.c
> -gnumach/i386/i386/idt-gen.h
> -gnumach/i386/i386/machspl.h
> -gnumach/i386/i386at/idt.h
For these ones, there is not much need to think deeply. These are
unquestionably kernel-internal. So if they are not used in building the
kernel, they can go.
> -gnumac
On Wed, Oct 18, 2000 at 01:26:19PM -0400, Roland McGrath wrote:
> > Ok, I've attached a listing of the old sate and the new state of
> > [gnumach]/i386/.
>
> I'm not sure what I'm supposed to glean from those lists of file names.
>
Well, you asked which files i modified/removed, and I'd still l
> > I didn't try anything else, because I was not able to compile
> > Dresden's L4Linux on FreeBSD (I used l4ka.org's glinux binary).
> > At least the root_task seems to work and this is very good for now.
> > Based on root_task, L4 servers can be build, probably with flux' oskit
> > (which compi
Hi,
[Kevin: would you please have a closer look at this patch? I'm not
an x86 expert and this is at best a premature first try at it. -Thanks]
the following patch:
http://home.kamp.net/home/farid.hajji/l4ka-bochs/
enables 4 MB superpages in bochs. With this hack,
you can boot (among others)
> Ok, I've attached a listing of the old sate and the new state of
> [gnumach]/i386/.
I'm not sure what I'm supposed to glean from those lists of file names.
> So which set of flags has advantage over the other?
It's not a question of "better flags". The flags need to be appropriate
for the se
Lee YoungNam wrote:
>
> PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMC8vRU4iPg0KPGh0
> bWw+DQo8aGVhZD4NCjx0aXRsZT5idWctaHVyZLTUIL7Is+fHz73KtM+x7j88L3RpdGxlPg0K
well bob what do you wanna say
either you are writin encrypted
or my mailer does not understand mime or somethin
but /you s
There has been some talk about what network abstractions are
appropriate when extending pfinet. There seems to be several
abstractions/interfaces that are needed in order to support
1. More network interfaces,
2. IPSEC processing,
3. Firewalling machinery,
4. Routing machinery and configuratio
On Wed, Oct 18, 2000 at 01:52:25AM -0400, Roland McGrath wrote:
> In oskit-mach, device_close is a no-op and releasing the last send right to
> the port returned by device_open is what closes the device. Then there is
> nothing extra to worry about, even in case of untimely death of translator.
>
On Wed, Oct 18, 2000 at 02:05:38AM -0400, Roland McGrath wrote:
> > I've looked through gnumach's machine dependent headers trying to see
> > where they could be replaces by equivalet oskit headers to eliminate
> > redundancy. So now I've eliminated most of the redundancy and removed the
> > unn
