[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Porting and Extending a TCP/IP noise simulator from kernel 2.2.xto 2.4.x
- To: guy keren <choo(at-nospam)actcom.co.il>
- Subject: Re: Porting and Extending a TCP/IP noise simulator from kernel 2.2.xto 2.4.x
- From: mulix <mulix(at-nospam)actcom.co.il>
- Date: Thu, 19 Jul 2001 17:40:07 +0300 (IDT)
- Cc: Shlomi Fish <shlomif(at-nospam)techst02.technion.ac.il>, <linux-il(at-nospam)linux.org.il>
- Delivered-To: linux.org.il-linux-il@linux.org.il
- In-Reply-To: <Pine.GSU.4.30_heb2.09.0107190450030.753-100000@actcom.co.il>
- Sender: linux-il-bounce(at-nospam)cs.huji.ac.il
On Thu, 19 Jul 2001, guy keren wrote:
> > 3. I'd like to use kernel debuggers like SGI's kdb and Personal ICE
> > (http://pice.sourceforge.net/) to aid in analysing errors. I know they are
> > not distributed with the kernel of Linus, but I suppose they can be
> > applied quite easily.
> >
> > Assuming the main kernel (which has both or one of the debuggers compiled
> > into it) has an OOPS fault, will they allow me to diagnose it?
>
> you don't need a debugger in order to get an OOPS message diagnosed. klogd
> does that for you, if you maintain an up-to-date symbol map. it'll
> translate the stack into kernel symbols offsets, and you could locate the
> relevant instruction by dissassembling your module.
if i recall correctly, klogd oops handling is deprecated, and you should
use ksymoops instead.
anyway, there's no need to worry about oopses yet. there's a very nifty
project called UML (User Mode Linux), which an implementation of a
kernel running as a user land process. one of the main advantages is of
course, the ability to code for the kernel and debug in user space, just
like you would debug any other c program.
more information is available at: http://user-mode-linux.sourceforge.net
> > 4. Naturally, to test the module, I'll need to simulate network activity. I
> > can do that with actual packets that arrive from different machine (or
> > from two different Ethernet cards on the same computer - %-)) but I could
> > also build an internal virtual network, and do some manipulations there.
> >
> > Or could I? I think depending on packets that arrive from the hardware at
> > the early stages of the project is a bad idea<tm>, because kernel
> > programming is bad enough without messing with the hardware. Naturally, we
> > will make sure it works with various hardware, but can we postpone it to
> > later stages? Should we do that?
>
> you could write your code so that you could compile it both in user mode
> and in kernel mode. then you could write the logics in user mode and test
> it there, and only when its debugged - put it in the kernel. i could send
> you the syscall tracker module's sources as an example of one way this
> could be done.
or you could use UML (see above). it supports networking using "virtual"
interfaces and network drivers.
> > So, what do you recommend regarding the issue of whether or not it should
> > be integrated into the main kernel? I think the patch to the kernel should
> > be #ifdef'd because delaying, ruining, or dropping packets deliberately is
> > something most people don't want to enable.
i think this is a question that should be ask on linux-kernel.
personally, i highly doubt this kind of patch would ever be integrated
(let me know in private if you want to know why).
> > Do you recommend joining or monitoring the linux-kernel mailing list. I
> > know the amount of daily messages there is very big, much more than all
> > the other mailing-list I am a member of. I could request a bigger quota to
> > accomodate for it, but I'll probably press the "D" button maniacly.
>
> i think i see muli waving his hand enthusiastically with a 'yes' vote :)
yup. small hint, though:
:0:
* ^Sender: linux-kernel-owner@vger.kernel.org
linux-kernel
:)
> but its more likely that for such a specifically targeted project, reading
> archives of such maling lists, and googling, and reading the kernel's
> source code, and purchasing a copy of alessandro rubini's "linux device
> drivers" book to learn how the kernel internally works - would be more
> productive.
i have the book here, if you'd like to peruse it. a new version should
be coming out, and i think i heard it will also be available in its
entirety on the web.
all in all, cool project, shlomi. in what class is it?
--
mulix
http://www.advogato.com/person/mulix
linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
=================================================================
To unsubscribe, send mail to linux-il-request@linux.org.il with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail linux-il-request@linux.org.il