Date: Thu, 2 Jan 1997 21:42:04 +1100 (EDT) From: Darren Reed <avalon@coombs.anu.edu.au> To: terry@lambert.org (Terry Lambert) Cc: avalon@coombs.anu.edu.au, terry@lambert.org, julian@whistle.com, luigi@labinfo.iet.unipi.it, proff@iq.org, danny@panda.hilink.com.au, hackers@freebsd.org Subject: Re: ipretard.c selective tcp/ip queues and throughput limiters Message-ID: <199701021045.CAA27880@freefall.freebsd.org> In-Reply-To: <199612310244.TAA01346@phaeton.artisoft.com> from "Terry Lambert" at Dec 30, 96 07:44:14 pm
next in thread | previous in thread | raw e-mail | index | archive | help
In some mail from Terry Lambert, sie said: > > > > This is what I've been calling "layering problems". It is definitely > > > a goal of mine to allow a module to be debugged in user space with a > > > source level debugger. > > > > Making code that compiles in the kernel also compile for user programs > > is tricky if you only want _one_ routine for both. > > I beg to disagree... PIC objects don't care whose address space > they are loaded or copied into... code is relatively addressed and > doesn't really care post-relocation if the relocation was by way > of ld -A or by way of dlopen. However, some simple functions such as malloc() are *much* different when compiled for kernel vs user. You can't compile a routine in user-space that uses mbufs without doing some extra work. Then you have to deal with spl's that don't exist, etc. And so on. I was thinking about this the other day and wondered how easy would it be to make the kernel compile as a user process ? Darren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701021045.CAA27880>