--- Marcus Brinkmann <[EMAIL PROTECTED]> wrote: > On Sat, Oct 18, 2003 at 03:13:59AM -0700, James Michael DuPont wrote: > > > Yes, it is very consistent and abstract. But, it is also > incredible > > > slow > > > and resource heavy, and enforces a lot of policy on the user. > This > > > slows > > > down the fast path, and introduces some interesting DoS attacks. > > > > OK, do you think that we can add in specific transformations and > rules > > into the compiler that will allow us to optimize some of this out? > I > > do. > > No, it's not possible. The problems are not in the implementation or > whatever local optimizations are possible, but in the interface > design.
Well, I see that it is difficult to uproot code that uses a set of abstractions to run on another set of abstractions. that is the type of stuff that i am working on, a set of code refactoring tools. We will see. > > What about a port registration utility that allows users to define > > ports to be bypassed via simple function calls and to define the > > semantics better? In a network environment you will want to have a > > client certificate to be attached to the port to know who is > attaching. > > Adding more features to the kernel will only make the matter worse. > Any particular addition can fix the one or other security problem, > but by > adding even more costs. i belive you. I need to look more into this, i am just starting. > > > So what do you plan on doing? > > We are working on a redesigned port to the L4 microkernel > (www.l4ka.org). Yes, I have gotten l4-hurd compiled and am working on the linker errors for pistachio. > > > > > > > And the Hurd is not difficult to compile either :) > > > > No, it was quite easy once I cleaned out the mach code, I dont see > why > > the entry costs for compiling should be so high? > > The entry cost for compiling is installing the Hurd, or installing a > vanilla > cross compiler. You did some odd, I have no clear idea what, but it > was > only complicated because you ignored the standard paths. I just made a new set of mach headers, without all this BS in it. > > Cannot mach/hurd run > > in user mode and be implemented as a set of linux constructs? > > For Mach, probably. Can BSD be compiled and run on Linux? Can > Windows be > compiled and run on OS/2? Maybe. It's not part of our project. > > And it has nothing to do with the Hurd. The Hurd needs the Mach > headers, > point. If you build a user space Mach for Linux, you still have to > install > a cross compiler and the Mach header files. > > The Hurd can _not_ run directly on Linux, and with high certainity > never will. > > > at least > > for the libstore and libstream/channel it should be possible to > test it > > under linux. > > I think you have still no clear idea what you are talking about. > Only parts > of that just need simple device access, others need the ports > functionality. > The same can be said of every software. Parts of ext2fs translator > can run > on Linux, but the whole can not. It's just a broken idea from the > start. I dont see why the libstream/libchannel could not be tested on a testing framwork under linux. It is just isolation that is needed. mike ===== James Michael DuPont http://introspector.sourceforge.net/ __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
